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

[Paul Fox]

ken wrote:
 > 
 > I'm assuming we don't want a biglock because that would cause more lock
 > contention, but maybe that wouldn't ever be a real problem in practice.
 > 
 > So I think now you're starting to see the mess that nmh locking is.  I was
 > close to cleaning it up, but I just got tired and I felt like I had crammed
 > enough stuff in for 1.5; if I kept trying to fix "one more thing", then 1.5
 > would never be released.
 > 
 > Here's roughly what I think should happen for nmh locking:
 > 
 > - Divorce nmh spool locking from regular file locking.  The fact that they're
 >   the same is an artifact of the code (there is only one set of lock
 >   functions).  There's no reason why they should be the same, and I can think
 >   of plenty of reasons why they shouldn't be.
 > 
 > - Make locking (both sorts) run-time selectable (see above; again, no
 >   reason, just historical practice).  Also make LOCKDIR selectable at
 >   runtime (if you're doing dotlocking).

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?

paul

 > 
 > - Implement mhlock (or nmhlock); like you said, it would be useful.
 > 
 > None of this is hard, it just would take time.
 > 
 > --Ken
 > 
 > _______________________________________________
 > Nmh-workers mailing list
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers

=---------------------
 paul fox, address@hidden (arlington, ma, where it's 42.8 degrees)