From: utzoo!decvax!cca!dan@Bbn-Unix@sri-unix
Newsgroups: net.unix-wizards
Title: Re: close problem on single-use devices
Article-I.D.: sri-unix.2787
Posted: Thu Aug 19 20:31:27 1982
Received: Fri Aug 20 05:18:34 1982

From: Dan Franklin 
Date:  9 Aug 1982  9:10:53 EDT (Monday)
One way I know of that locking might not get undone on a signal is the general
UNIX open bug. For any device which sleeps at interruptable priority in its
open routine, if a signal comes along while it is sleeping there, control
jumps directly back into the trap routine, bypassing any little cleanup like
deletion of the fd, clearing out the lock bit, etc. This problem was alluded
to in an earlier message about file descriptors which suggested the user-level
hack of "predicting" the fd before doing the open, and then, if the open
failed, closing this fd. 

A simple solution for the locking problem might be to avoid locking until
after the sleep; however, this means that several processes can contend for
the device until that time, which might defeat the purpose of locking for your
application.

A general solution is to have devices which sleep in the open routine at
interruptable priority make a copy of the value of u.u_qsav and set up their
own handler for interrupts (via a "save" into u.u_qsav) just before going to
sleep. Then when an interrupt occurs, the code should clean up as necessary
and resume at the saved value of u.u_qsav. I haven't tried it yet, though; in
the one place it hurt us, in the network mailer (which would run out of fds),
'predicting' the fd was enough. 
	Dan Franklin