🚀 go-pugleaf

According to rwhite@nusdecs.uucp (0257014-Robert White(140)):
>In article <274975C4.21C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>> According to rwhite@nusdecs.uucp (0257014-Robert White(140)):
>> >Do the "put process number in lock file" thing as in uucp.
>> For you doubters: Once you've determined that a lock file is stale and
>> you want to unlink() it, how do you know the lock file hasn't been
>> replaced in between the decision to unlink() and the unlink() itself?
>
>The above is (except for my comment) incorrect.  The application of the
>basic rules of computer science reveals the following procedure:

Mr. White thus reveals that what he lacks in reading comprehension he
makes up for in pomposity.

Had he read the first part of my article, he would have noticed the
qualification emphasized below:

In article <274975C4.21C@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
> This approach cannot be used reliably without either (1) having a lock
> held forever by a dead process, which I find unacceptable, or (2)
> using a kernel locking call, which renders the pid file redundant.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It is excruciatingly obvious that kernel locking calls are sufficient
to provide serial access to a file, thus guaranteeing lock file
integrity without requiring unlinking and linking.  Exclusive access
based on kernel record locking primitives is child's play.

In any case, my point was that creating a lock file, and then updating
it safely using kernel locking primitives, is silly if the resource in
question can be locked directly.
-- 
Chip Salzenberg at Teltronics/TCT     <chip@tct.uucp>, <uunet!pdn!tct!chip>
    "I've been cranky ever since my comp.unix.wizards was removed
         by that evil Chip Salzenberg."   -- John F. Haugh II