Ken wrote:
Obviously locking on the spool file should match whatever
locking the local delivery agent uses. But let's look at the
"everything else" case.
Lyndon makes the case here:
http://lists.nongnu.org/archive/html/nmh-workers/2012-02/msg00050.html
That the default should be "flock". The more I research it
... the more confused I've become. fcntl() locks have the
unhappy behaviour (as Lyndon notes) that any close of a
descriptor holding a fcntl() lock will remove the lock (even
if there are other descriptors open that for the same lock).
(within the process)
Is this a problem for nmh? I don't think so. Here's what
we do in context_save():
if (!(out = lkfopen (ctxpath, "w"))) adios (/* not shown */);
/* write the context to the file */
lkfclose (out, ctxpath);
And similarly for the sequences file in seq_save(), the MIME
content cache map file in mhcachesbr.c, and I think the uses
of lkopen() in annosbr.c, dropsbr.c, and slocal.c. No
forks, and because of open-read/write-close paradigm, I
don't expect that we have multiple open fds hanging around
on these files. At least we shouldn't.
lockf() does record locking, but cannot do a shared lock.
And on many platforms, lockf is implemented using fcntl. So
I don't think lockf serves any useful purpose and should not
be used as a default for nmh. Or even as a configure
option, but it's already there and not getting in the way.
flock() is not part of POSIX, but it seems like everyone that
I checked supports it.
We default to it on the bsd's and Mac, I assume because of how
they lock the mail spool. But . . . flock on Linux doesn't (or
at least didn't) lock files over NFS; for me, that's a good
reason to never use it there. And Lyndon noted that flock on
Solaris is just a wrapper around fcntl.
If someone wants to use flock where it's not the nmh default,
they can configure it at their own peril.
So ... suggestions?
We could change the current configure --with-locking to not
apply to the spool file lock. For that, and the nmh state
file locks unless overridden, use what configure now picks
for the default lock method. In other words, --with-locking
would only apply to the nmh state files. I think that
agrees with what Lyndon suggested, putting aside the default
lock method choice.
About the only possibly useful change I could see would be to
allow both kernel locking and dot locking on a file, maybe even
on the mail spool file, for someone who's using some mix of
programs that use different, or unknown, locking methods.
But I don't need that and I don't need to override the default.
And the more complicated we make this, the harder it will be to
use correctly. So I'm happy the way things are now.
And none of this will fix the problem with multiple processes
being able to mangle the nmh state files. So I think our
efforts would be better spent on that. Instead of the current:
open file, lock file, read file, unlock file, close file
update sequences
open file, lock file, write file, unlock file, close file
Would the added steps in [] below help?
open file, lock file, read file, unlock file, close file
[save entire file contents]
update sequences
open file, lock file
[read file]
[compare current file contents to saved file contents:
if the same, then write file
if not the same, then complain and leave file as is]
unlock file, close file
The user could see that there was a collision and wouldn't have
mangled files.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers