Public Comment Number PC-UK0096 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1998-02-25 Author: N.M Maclaren Author Affiliation: Self Postal Address: University of Cambridge, Computer Laboratory, New Museums Site, Pembroke Street, Cambridge CB3 3QG, United Kingdom E-mail Address: Telephone Number: +44 1223 334761 Fax Number: +44 1223 334679 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 7.11.1.1 Title: Signal handlers and signal classes Detailed description: The wording of paragraph 3 is better in C9X than that in C89, but still bears little relationship to reality. Even under Unix, returning from a SIGINT handler is as likely to cause trouble as returning from a SIGFPE, SIGILL or SIGSEGV one. One reason for this problem under Unix is that ANY signal causes some system calls to be aborted, and many of those do not provide enough information to enable them to be restarted transparently; socket I/O is a particularly grim area in this respect, as an aborted read() or write() does not reliably indicate how much data was successfully transferred (see POSIX.1). This problem is one of the reasons that Unix utilities occasionally crash with a SIGSEGV after having trapped and recovered from another signal. I could go into some length about consistency problems in compiled code, even though I know only a few architectures at that level, but I can say that the problems are getting worse and many of them are blurring the distinction between synchronous and asynchronous signals (not that there every has been a clear boundary). Consider the latest 'fad', for example: multiple CPU threads of execution within a single software thread (or even software threads), and then consider which thread should handle a signal and what it should do about the others while doing so. These problems often mean that it is HARDER to trap and recover from an asynchronous signal than from one like SIGFPE (which at least has a single associated thread). And, lastly, there are many systems where returning from a system-generated signal of the SIGABRT variety is an absolute no-no! I suggest replacing the last sentence by the much simpler and more general: The implementation may define circumstances in which returning from a signal handler leads to undefined behaviour; otherwise the program will resume execution at the point that it was interrupted.