[Top][All Lists]

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

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

From: Ken Hornstein
Subject: Re: [Nmh-workers] Locking. Horrible, horrible, locking ...
Date: Mon, 01 Jul 2013 11:48:46 -0400

>> But ... why?  I mean, seriously.  That means that people who use
>> system-provided nmh packages lose.  I always thought compile-time
>> configuration was something that was to be avoided.  What exactly is
>> your beef with making it runtime configurable?
>Code complexity.

Fair enough ... but the most complexity really comes from the run-time
code selection, and that's already in place.

>> And how come you're bringing this up NOW, instead of when we hashed
>> this all out in March?
>Because I hadn't run across the current Solaris 11 behaviour.  Which
>would have pushed the point a lot harder.  I didn't like it back then,
>but I didn't have a definitive example of where it would break things.
>Now I do.

Alright.  I could be persuaded to be neutral on this if you really
object that much (although, I can't really see the harm of keeping
the runtime configuration around ... it seemed like there was enough
confusion about the right locking protocol to use on an NFS-mounted mail
spool that there was some value there).

But I do have a practical question about the use of the maillock functions
you posted.  Right now you can "inc" any file, and nmh doesn't know that
the file is a mail spool; it just knows there's a default file to inc
from.  The maillock() functions you posted only take a username as an
argument, and obviously they're only appropriate for locking the actual
spool file.  To make that work properly you're going to have to add some
code in there to distinguish between opening a spool file and some other,
random file.  Also I suppose technically you need to be sure that you're
not opening some other mailbox that's not your own (I don't know how
common that is).  None of those things are impossible, but it's going
to be a bit of a mess.

>Regardless, the mbox locking needs to be completely divorced from the
>rest of the nmh locking.  There is too much ambiguity in the code to
>believe that we are doing either side of it correctly.

I guess I don't understand this statement.  What ambiguity are you talking


reply via email to

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