Re: Synchronization Problem

[kat]

norm@dad.org writes:
> Ken Hornstein <kenh@pobox.com> writes:
> >>But after the scan is complete and before I do the rmm, the script might
> >>have put a new message in +inbox, which rmm would remove.
> >
> >There aren't _wonderful_ solutions, because this is a higher-level problem;
> >other programs can change the state of your inbox between commands.
> >Unless you want to do something like Kevin Cosgrove suggested, this is
> >fundamental to your design.  You could do some higher-level locking
> >where you prevent your script from running while you read your inbox.
>
> I solved my particular problem by realizing that inc works fine when I point
> it to a file containing just one message and no message dividers.
>
> But it does illustrate what I think might be a more fundamental problem with
> nmh: there is no way for that a user-written script can participate in nmh's
> internal locking mechanism

Access to internal locking mechanisms would be nice. A related thing that
would be nice would be if commands would have flags not to modify state.
An example is inc -nochangecur, but I want one that goes further than
this, refraining from modifying the context and the cur sequence.

norm@dad.org writes:
> So I wonder if there is some way that this problem could be
> resolved. Would it be very hard to implement a couple of new nmh commands?
> Maybe something like this:
> 
>      nmhlock  [ -timeout milliseconds] (returns a token in stdout)
>      nmhunlock token
> 
>     Norman Shapiro

Having used nmh but not having read the relevant source code,
my impression is that there is not one global lock; rather, there is
a separate lock for each mbox file, for the context file, and
for each .mh_sequences file. Would someone expound on this?

Here are some things I do instead of using the internal locks.

  For interactive commands, I know not to run multiple conflicting
  programs at once. I fetch mails to an mbox regularly with getmail and
  cron, (Even better is to have them mailed to the host you are running
  nmh on, but that is hard because mailers have become so incorrectly
  picky about how the receiving server should act.) and then I can
  quickly load them with inc whenever I want to view new mails.

  In some cases I check for running user processes instead of a lock.
  I figure, if I am not logged in, some things may be okay, even though
  there is still a race condition. I use this for deciding whether it's
  okay to print out my emails and remove them from the Unseen-Sequence.
  See ejmejl rprint.in, attached or at this address:
  https://krabben.twilightparadox.com/fossil/ejmejl/artifact/7ef31229d55087eb

  When simultaneously executed commands promise to keep to separate
  folders, I create a fake HOME directory. This is how I use nmh as
  a contacts manager. See ch lib/ch/init, attached or at this address:
  https://krabben.twilightparadox.com/fossil/ch/artifact/995b419bf1629c6f

  When two programs might using the same folder but one only reads,
  I tried setting the .mh_sequences mode to 640 and having another
  user access the folder, but I think the file got modified anyway.
  I guessed the program might have used setuid, but I didn't figure
  out why that happened. Another possibility in this case would be
  to symlink all of the messages to a different folder with a different
  .mh_sequences file.

I missed the suggestion of Kevin Cosgrove. Could you refer me to that?

With Appreciation,
Krullen Van De Trap

rprint.in
Description: rprint.in

init
Description: init