>>it is now (unless you wanted to do the equivalent of a biglock; we don't >>want that, do we?). > >I don't know why we don't want that. But there is no reason why I need to know. >At this point I retire from this locking discussion with the hope that I don't >gag on all the feet in my mouth.
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). - 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@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers