Re: [Nmh-workers] Locking In Scripts and nmh Locking

[Ken Hornstein]

>this is just curiousity on my part:  why does it matter?  i've always
>figured that compared to the expense of actually doing things to the
>files one is locking, the taking and releasing of the lock itself is
>in the noise, performance-wise.  is one set of locking primitives
>that much better than another?

Yeah, it matters.  For one, different filesystems (think network filesystems)
can handle different locking primitives in different ways.  I'll give you
one personal example.

I have my mail folders in AFS, a wide-area filesystem.  AFS does pretty good
on reads and stats over the wide area, but not so great at creates; this
is unavoidable, because each create involves a round-trip.  With dot-locking,
there are actually four round-trips (one to create the temp lock file,
one to link to the actual lock file, and then two to remove the temp file
and lock file).  That adds up, since a single "show" can cause two or three
files to be locked.

What I discovered is that it makes a huge difference if I set LOCKDIR
to /tmp on my laptop when travelling.  Locking is consistent on a
single machine and I save four round trips, which matters a whole
lot especially when dealing with modern congested bufferbloated
networks.  Now I can get corruption if I run two simultaneous nmh
commands on two different machines, but I know that and I make sure
not to do that (on work machines I don't set LOCKDIR since the added
round-trips are not noticable).

Is this a common case, or even useful for most people?  No way.  But I
know I can't imagine all of the ways nmh is being used, so I think maximum
configurability (with sensible defaults) is the way to go.

--Ken