Re: [Nmh-workers] Locking. Horrible, horrible, locking ...

[Ken Hornstein]

>But wouldn't the split be: (spool) mbox on the local filesystem, $HOME
>on NFS?  And if it was further fragmented, we can't get down to that
>level of granularity, anyway.  (Well, maybe we can on a per-tool basis
>-- I haven't traced the code that deeply yet -- but that seems like a
>very contrived situation.)

Well, I've seen a bunch of situations where it was the reverse (spool on
NFS, $HOME local).

>I can't recall any other software (other than regression testers
>designed to break things) that supports changing the locking at run
>time like this.

Well, here's my thinking on the subject.

When we discussed these things in March, pretty much every default answer
you could give for the locking function to use had someone that had a
counter-example showing why that was the wrong choice.  So, that's
problem A: no answer is correct for everyone, even on one platform.

Problem B is that a lot of people only use pre-compiled binary packages,
and they're reluctant to compile their own.  That's a simple fact that
we've seen born out many times by users on the mailing list.  So that
means that whoever builds the binary packages is making the decision for
a lot of people ... and frequently that decision is wrong.

Given those things I felt the best solution was to make the locking
run-time selectable.

--Ken