Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site utcs.UUCP Path: utzoo!lsuc!utcs!geoff From: geoff@utcs.UUCP (Geoff Collyer) Newsgroups: net.unix-wizards Subject: Re: Printing in signal handlers (more on ( alarm(1) == alarm(INFINITY))? Message-ID: <542@utcs.UUCP> Date: Thu, 21-Mar-85 01:23:34 EST Article-I.D.: utcs.542 Posted: Thu Mar 21 01:23:34 1985 Date-Received: Thu, 21-Mar-85 02:29:17 EST References: <312@calgary.UUCP> <2175@wateng.UUCP> Reply-To: geoff@utcs.UUCP (Geoff Collyer) Organization: University of Toronto - General Purpose UNIX Lines: 29 Keywords: signal catching Summary: keep signal handlers short & simple In article <2175@wateng.UUCP> ksbszabo@wateng.UUCP (Kevin Szabo) writes: >The problem is that practically none of STDIO is re-entrant. The only >thing you can trust in a signal handler is a direct call to the kernel. I think the real problem is that UNIX allows one to catch signals at all. Given that we don't have cheap processes a la Thoth, catching signals is a necessary evil but signal handlers should be kept simple and in particular should avoid using longjmp (if you have ever read and understood the source, you won't want to use longjmp). At most, setting a global flag often suffices; this also may allow one to omit calls to signal to enable and disable signal catching around critical sections by simply noting the state of the flag at appropriate places. I can't speak for all UNIXes, but the system call interface routines in the PDP-11 v7 C library often aren't re-entrant either: they copy their arguments into static storage, then issue the system call pointing at the static storage. If you interrupt such a routine (say signal(2)) while it is copying its arguments and in the signal catcher you invoke the same system call, then return from the signal catcher without calling longjmp, the first instance of signal will continue to execute, though some of its static storage was trashed by the second call in the signal handler. So if you are going to make those direct calls to the kernel in your signal handler, you'd better do it from assembler or verify that your C library system call interfaces are re-entrant. This is something that I believe Whitesmith's got right: last time I looked they had a standard routine for issuing system calls that left the arguments on the stack and made the system call point at the stacked arguments.