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 FranklinDate: 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