On Sat, 9 Nov 1996, Don Lewis wrote:

> I worry about things like putting the pid in the lock file for such
> purposes.  What if the process holding the lock dies without removing
> the lock file, and when you get around to checking on who is holding the
> lock, the process ids have wrapped around and some innocent process now
> has that pid?

Well, it looks as if it's locked when it's not. It could be a
problem for production systems, if a long-lived process somehow
gets that same PID. This is, however, not going to be a terribly
common occurance, and is easily fixed by hand. Also, a watchdog
for this is not hard to write if this is a serious concern.

> Then there's the problem of someone manually clearing the
> lock by removing the lock while some process is still talking to the device.
> How do you recover from that?

The processes then blow up if something else tries to read from or
write to the device. No big surprise; a nitwit with root access
can blow up a lot of things on a system.

> With kernal locks, the lock has to be held by a process that has the
> device open.  If the process dies, the lock is unlocked.  You can find
> out what process(es) have the device open (thus locking it) with fstat.

True enough. On the other hand, if a processes wedges (gets stuck
in a non-interuptable state, such as waiting for disk I/O), that
device now remains locked forever and you have to reboot your system
before you can have access to it.

Neither system is perfect, but I think the consequences of messed-up
userland locks are a little less serious, and userland locks give
you a feature you don't have otherwise.

Another thing you can't do with kernel locks is to lock the port
without bringing up DTR, which you might want to do if you wanted
to await an incoming call that you don't want your modem to answer,
for example.

(Actually, come to think of it, you'd need some special hacks in
the kernel to deal with DTR, too, otherwise incoming and outgoing
calls wouldn't be compatable. When getty does its open, DTR must
come up so that the modem will answer a ring. However, at this
point getty cannot have the port locked, because that would prevent
uucico from dialing out. So uucico does a dialout, does its thing,
and then closes the port, which is supposed to drop DTR and hang
up. The kernel at this point has to have some code that will bring
down the DTR for a certain length of time, and then bring it back
up again, despite the fact that getty is still hanging in that very
same blocking open that brought up DTR that was called before the
uucico session. This isn't terribly pretty.)

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.	
Vancouver, BC   (604) 257-9400		De gustibus, aut bene aut nihil.