>> What I would do is this.

>> 	do {
>> 		if flock() fails, continue;
>> 		if dot lock fails, release flock, continue;
>> 	} sleep(1 += a little);

>> or something like that.  That should give all the programs a
>> chance...

> As Mouse correctly points out above, it also introduces a potential
> for deadlock should some other piece of software, be it elm,
> procmail, fetchmail, an imapd, etc. try locking in the reverse order.

Actually, as written, it doesn't.  The "release first lock and retry"
when the second lock fails, coupled with a varying backoff interval,
avoid that danger.

Of course, the algorithm is now not starvation-free; it's possible for
a process to be starved out even though the locks keep getting released
and re-acquired.

However, I think that may be unavoidable; I don't recall any promises
that pure flock() locking is starvation-free, for example.  (A good
implementation will be, but I don't think it's part of its interface
spec.)

> Or do you propose that we "fix" all of those, too?

Any program that does locking needs attention.  After all, you don't
want elm to fail to lock against procmail, just because one uses dot
file locking and the other uses flock()....  (That's a hypothetical
example; I don't know what locking schemes those two actually use.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B