[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] Locking In Scripts and nmh Locking
Date: Wed, 02 May 2012 19:32:01 -0400

>>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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]