Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!zephyr.ens.tek.com!tektronix!sequent!jjb From: jjb@sequent.UUCP (Jeff Berkowitz) Newsgroups: comp.unix.wizards Subject: Re: tip processes on the SUN Summary: It's a bit worse than that Message-ID: <26872@sequent.UUCP> Date: 27 Dec 89 18:31:19 GMT References: <21875@adm.BRL.MIL> <1000@ursa-major.SPDCC.COM> Reply-To: jjb@sequent.UUCP (Jeff Berkowitz) Organization: Sequent Computer Systems, Inc Lines: 37 >In article <21875@adm.BRL.MIL> swenson@nusc-wpn.arpa writes: >> We are using the standard tip line to a remote VME cage... >>...the tip line loses its mind...Try to kill the process -- it won't die. In article <1000@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >You can issue a "kill" as much as you want. What it will do each time, >however, is to interrupt the sleep and restart the exit code. This statement suggests that the person who wrote the driver didn't bother to look and see whether a signal occurred (and abort the close if so). Actually it's worse than this on many flavors of UN*X. I can't speak for System 5, but on most (all?) BSD-derived systems the code in exit() does p->p_sigignore = ~0; fairly early in exit() processing. The code [actually in rexit()] then loops through the descriptors, closing them. The effect is that all signals, even SIGKILL, are ignored during close processing. In fact, they're actually thrown away; the fact that they occurred is not even recorded in the p_sig word. What this means is that (1) during exit(), any sleep in the driver is TOTALLY uninterruptible, and (2) the careful driver-writer doesn't even have the OPTION of polling the device, checking periodically for signals, and aborting the close if one arrives. This is difficult to solve. Most signal processing should certainly be disabled while the process is half-disassembled. I don't think anyone wants to add more state to the signal code, which is already grotesque. Just throwing away buffered characters on a flow controlled line at close() time isn't really acceptable either; the device could be, say, a printer which has been punched "off-line". When it goes "on-line", the owner deserves to get the end of the listing. -- Jeff Berkowitz N6QOM uunet!sequent!jjb Sequent Computer Systems Custom Systems Group