jjb@sequent.UUCP (Jeff Berkowitz) (09/07/90)
Regarding tty lines hung waiting for a ^Q: In article <1990Sep4.083053.4611@celebr.uucp> jbm@celebr.uucp (John B. Milton) writes: >>>>>>> On 29 Aug 90 15:44:50 GMT, Leslie Mikesell <les@chinet.chi.il.us> said: >>les> ...I've even seen cases where the device driver would lock up so >>les> that even a kill -9 wouldn't release the process... >> >>I've seen this problem quite frequently using terminals with XON/XOFF >>handshaking... Many BSD based tty subsystems have the "wait forever for output to drain on close" philosophy. In addition, the code in exit() masks (ignores) all signals, even sig 9, before looping through the descriptor table calling close(). Suppose the driver's close routine is entered from exit() and just then a ^S arrives. The driver (correctly) stops sending. Imagine that now carrier drops. Since all signals are ignored, the SIGHUP is thrown away. A ^Q will never arrive since the connection is gone, and the process can't be killed since all the signals were ignored back in exit(). You also can't issue an ioctl() to clear the port, because it's in the LCLOSE state - no open() will complete, so you can't get an fd to issue the ioctl() on. You are stuck. Absolutely the only thing that will clear this condition is to unplug the modem, plug in a terminal, and pump a ^Q into the port. Note that ignored signals are discarded without even being recorded in a mask word, so the clever driver developer can't even get around this by sleeping on lbolt in the close routine and checking every second for newly-arrived signals. Sigh... :-) -- Jeff Berkowitz N6QOM uunet!sequent!jjb | Bugs are God's way of saying Sequent Computer Systems | you have too much free time.