Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!gwyn@brl-vld From: gwyn%brl-vld@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: improved 4.2BSD signal(2) library routine Message-ID: <15104@sri-arpa.UUCP> Date: Tue, 3-Jan-84 14:18:45 EST Article-I.D.: sri-arpa.15104 Posted: Tue Jan 3 14:18:45 1984 Date-Received: Sat, 7-Jan-84 02:17:49 EST Lines: 21 From: Doug Gwyn (VLD/VMB) It is easy enough to patch the previously posted signal(2) emulation to at least make sure that EINTR is only returned for system calls that are supposed to be able to return this indication; I can send the amended routine to anyone who wants it. It is true that some reads or writes that should not be interruptible (disk file i/o) may return EINTR on rare occasion, although that should not bother stdio users. The real botch in the new signal handling, as I see it, is that there is no reliable way (short of snooping in one's u_ area on architectures that allow that) to determine if one is in the middle of a system call when the signal is fielded. It appears that the new facilities were designed with a specific model of how programs do i/o and use signals, and that model does not fit every application. There are many times when I DO NOT WANT terminal i/o restarted after a signal, especially after a keyboard-generated signal. This is difficult to arrange when terminal i/o gets automatically restarted by the system! I can't be as enthusiastic over people's "courage" to try to improve things when they don't take sufficient care in the new design.