how to exit from a signal routine

[Louis Stroucken 42720]

In article <7997 at cbnews.ATT.COM> mark at cbnews.ATT.COM (Mark Horton) writes:

[example on the handling of interrupts deleted]

>Then Berkeley 4.2BSD changed how signal worked, and if the handler
>returned, the read would just resume.  It became accepted wisdom
>among authors of highly portable programs that the longjmp approach
>was the most portable method.  (Checking, this is true of 4.2BSD
>and 4.3BSD, but SunOS 4.0 does it the System V way.)
>
>Now ANSI C has decreed that you can't call longjmp, or any other
>function except signal, from inside a signal handler for any signal
>except those raised by abort, raise, or SIGFPE.

Sounds like my programs will not be as portable as I would like them to
be :(.

Can anybody quote the standard's exact wording on this issue?
Especially, will the following trick be legal?

	jmp_buf env;

	void handle_by_jump (int sig) {
		longjmp (env, sig);
	}

	void handle_by_raise (int sig) {
		(void) signal (sig, handle_by_jump);
		raise (sig);
	}


>  The reason given
>for this is that you might be in the middle of calling that function
>already when the interrupt comes in, and C library routine are not
>required to be reentrant.  You can't call longjmp to get out of a
>signal handler because maybe the code was in the middle of calling
>longjmp when the signal came in.  Obscure, but they're right.  (On
>the other hand, I can't see the harm in reentering longjmp, you'll
>never get back to the first call.)

Sounds like above trick wont work...

>So where does this leave the developer?  ANSI C says the only way
>to exit from a SIGINT handler is to return.  The routine is supposed
>to pick up where it left off, ala 4.2BSD (although the System V
>behavior of having the read return EINTR seems to be allowed too.)
>Even if you pretend 4.*BSD doesn't exist, you can imagine the
>complexity of checking for EINTR after every terminal read, if
>you call handy stdio routines like getchar, scanf, and fgets.  (Nobody
>calls gets anymore, right? :-)

Yeah, where does this leave the developer? In our case, we are
developing an application consisting of several cooperating processes.
We use handle_by_jump type signal handlers to ensure that a process will
not get into serious trouble without at least notifying its partners
it's going to die. What other approaches are available?


> Mark Horton

Louis Stroucken
strouckn at nvpna1.prl.philips.nl