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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=---------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 42.8 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers