<exiting> tip processes on the SUN

[Jeff Berkowitz]

>In article <21875 at adm.BRL.MIL> swenson at 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 at ursa-major.SPDCC.COM>
  dyer at 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