Re: [Nmh-workers] Locking - which to use?

[Lyndon Nerenberg]

> 
>> configure should be able to set this on a per-platform basis.
> 
> It can't because it depends on what other applications use.
> 
> Fedora /bin/mail uses fcntl and Mutt recommends it.
> procmail can use it.  I haven't had any problems since I
> starting using fcntl.  I did see problems with dot locking,
> I expect because other applications weren't using it.

As Ken mentioned earlier, there are two types of locking at issue:

1) System mailbox locking

This must use the same scheme as the platform's /bin/mail and friends use. The 
configure script needs to set the appropriate value based on the platform it's 
being run on. Configure also needs to determine whether inc needs setgid on 
that platform. The user should never have to override these, and I don't think 
we should even provide a knob to let them to do so.

2) nmh internal locking

This can be whatever makes the most sense for nmh itself.  Again, configure 
should have knowledge to set this to a reasonable platform-specific setting. My 
guess is it would default to flock, with platform specific overrides where it's 
known flock doesn't play nice.  This one definitely needs a knob to allow the 
user to override the default.


The reason to shun fcntl locking is this (from SUS v3):

  All locks associated with a file for a given process shall be
  removed when a file descriptor for that file is closed by that
  process or the process holding that file descriptor terminates.
  Locks are not inherited by a child process.

This means that dup()ing a descriptor to a locked file, and then closing either 
of those fd's will kill *all* locks on that file, no matter which fd they were 
acquired on. This can wreak havoc when you have library routines that are doing 
file descriptor manipulations behind the scenes. And beware flock on Solaris, 
which is just a wrapper around fcntl.

--lyndon