Re: Synchronization Problem

[Ken Hornstein]

>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 -- or if there is I don't recall where it is
>documented.

Well, here's the thing ... there is no "nmh internal locking mechanism".
Never has been!  There's a perception that it is okay to run two nmh
commands simultaneously ... THAT has never been true, ever!  This goes
back to the original MH design, when people were using glass terminals
and nobody would ever run two commands at once.

Now, let me expand on that a bit, because that's one of those things that
is mostly true, but there are some (important) exceptions.

When a new message is added to a folder (via folder_addmsg()), THAT is
safe.  What happens there is a temporary file is created in the folder
and link() is used to create the "final" name for it.  If that link()
fails then the new message number is incremented and the the link()
is tried using a higher number.  folder_addmsg() is used by refile,
rcvstore ... but NOT by inc!.  If you change the state of a folder
while inc is running, it could happily overwrite a message!  So,
don't do that.

Now, along the way Paul Vixie got tired of his sequences file getting
corrupted by rcvstore when he'd run another (n)mh command so he
contributed patches for locking the sequence files.  Those kind of were
broken for a while (there were versions of nmh that would try locking
"/tmp" ... good times) but I believe we've cleaned all that up, and now
it should be in reasonable shape.

But ... it's important to understand the goals of these changes.  The
goal was to make it so two processed wouldn't write to a sequence (or
context) file at the same time, which could cause a corrupted sequence/
context file and break nmh.  That no longer happens.  But ... we never
made any guarantees that the DATA written to that sequence file was
always correct.  There could easily be a sequence of things that could
happen where messages could get removed from a sequence when they
weren't supposed to, or a message remained on a sequence when it should
have been removed.  Now, when I cleaned up locking I tried to make it
sensible and we MAY now have a situation where, effectively, most commands
"global lock" on the sequence file.  But that is not a guarantee and I
would not depend on it; that was never a goal and there's no guarantees
that it won't change in the future.

So, I would say ... it's (mostly) fine to run rcvstore in the background
with other commands.  But any two other nmh commands simultaneously?
Absolutely not.  DEFINITELY not inc.

--Ken