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