[Mailman-developers] More mailman locking issues

[Barry A. Warsaw]

>>>>> "KM" == Ken Manheimer <klm@python.org> writes:

    KM> It might be sufficient to offer a way to open a list
    KM> "read-only", such that no locking is done.  I think it would
    KM> be better, however, to refine the locking system such that
    KM> lists are not locked until they enter an operation that
    KM> changes the list data in a way that will eventually need to be
    KM> written.  This would probably take a more effort than a
    KM> "read-only" kluge, but may not be too bad.

Of course, much of these file-locking problems go away once you have a 
long-lived mailman server.  Then again, you'll have threading issues
to deal with :-).

I haven't looked at what it is that Mailman is actually trying to lock
(too busy interspersing autoconf hacking time in with Real Work), but
I'm guess from what I've read that you're just trying to keep multiple
writers from clobbering each other (and readers from reading
inconsistent data when a writer is writing).  It sounds like you don't 
really need to lock the file, but instead to lock out access to a
shared resource, and you want this to work across NFS.

I wasn't able to dig up the Netscape Mail + File Locking article that
Jamie Zawinski wrote.  I don't seem to have it in my bookmarks or
easily grepable and a web search turned up only stale links.  I
emailed Jaime to see if he's got an updated link and will forward that 
if I get a response.

If I remember correctly, the article basically justifies the point of
view that the best portable way to do resource locking across NFS is
by creating a file with O_CREAT | O_EXCL.  That's what's meant by
"dot-file" locking because you usually create a .file that is mostly
invisible.  Since the check-for-existance and file-creation steps are
atomic (on Solaris at least), you won't every have two processes step
on each other.  The additional advantage is that just rm'ing the
dot-file is enough to unlock the system.  The disadvantage is that
this operation may not be atomic for older versions of NFS, although I
believe it is for NFS 3 (can't find a reference to this right now
though).

On the other hand, creation of directories *is* atomic across all
versions of NFS, AFAIK, so perhaps it makes more sense to create a
dot-directory that locks the resource.  You'd have to use mkdir() and
check for EEXIST.  You'd basically busy-loop in either case waiting
for the lock to be given up.

So creating a dot-directory representing a lock is probably the
most portable, safest, and easiest way to do it.

-Barry