Subject: Re: Mail and locking
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
List: current-users
Date: 12/03/1996 10:46:41
>> 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

> 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

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B