Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!husc6!think!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!hpda!hpcupt1!davel From: davel@hpcupt1.UUCP Newsgroups: comp.unix.questions Subject: Re: msleep Message-ID: <6060002@hpcupt1.HP.COM> Date: Fri, 4-Dec-87 18:00:05 EST Article-I.D.: hpcupt1.6060002 Posted: Fri Dec 4 18:00:05 1987 Date-Received: Wed, 9-Dec-87 22:57:39 EST References: <332@PT.CS.CMU.EDU> Organization: Hewlett Packard, Cupertino Lines: 30 > / chris@mimsy.UUCP (Chris Torek) / 12:38 pm Nov 18, 1987 / > > In the presence of longjmp, C needs an unwind-protect mechanism. This is an intriguing idea. I like it. But it does require that all functions used (e.g., from a library) are correctly coded to use the unwind-protect mechanism as needed. I guess that goes without saying (so I said it ;-) ). My posting was meant to assume that standard unix signal handling precautions were being followed. It is known (and even documented in Posix !) that it is unsafe in the general case to do anything in a signal handler but the most simple things. (For example, set a variable or longjmp to a state which itself does trivial cleanup and exit.) (Worrying about the general case is very important for a library routine which establishes signal handlers, e.g., sleep().) However, if the application limits what is going on during the interval of time when the signal handler can be entered (e.g., make sure you aren't in stdio) then you have more freedom in the signal handler. Specifically, I was discussing the case where SIGALRM was used to timeout a system call. The longjmp() in this case merely returns to the same routine that invoked the system call; no stack frames are unwound at all. Thank you for pointing out the pitfalls in the general case and for describing the unwind-protect mechanism. -Dave Lennert HP ihnp4!hplabs!hpda!davel