[Nmh-workers] Locking. Horrible, horrible, locking ...

[Lyndon Nerenberg]

I have spent the worse part of the day trying to make sense of how we configure 
locking.  A waste of a perfectly good long weekend, I know, but once something 
starts annoying me ...

While lock_file.c differentiates between "spool" locks (I would call it the 
mbox lock) and "other" locks, the configure scripts don't really seem to 
provide a tried-and-true method to hardwire down each (should that be desired). 
 I.e. the assumption at ./configure time is that one size fits all.  But it's 
also possible to override the types at runtime in the profile.

Oracle Solaris 11 throws a wrench into the mix.  It has obliterated flock(), 
and in the course of fixing that up I stumbled across maillock(3MAIL), which 
provides a set of functions to manipulate the locks on the "spool" mbox.  But 
they are very specific to locking only the user's "system" mailbox.  E.g.:

  int maillock(const char *user, int retrycnt);
  void mailunlock(void);
  void touchlock(void);

Obviously these are not suitable for use on anything other than the "spool" 
mailbox, so it makes no sense to make these available for general use via the 
profile.

But now I'm asking "why would anyone want to change these?"  On any given UNIX 
platform, there is one way to lock files in the general case (and perhaps 
separately in the mbox case), and every other app I've seen just compiles in 
those methods and calls it a day.  Do we really need to be able to switch this 
stuff at run time?

--lyndon