longjmp() from nested signal handlers

[Kent Forschmiedt]

[ various discussion about promises (or lack of them) regarding
  the condition of one's data segment after longjmp() from a
  signal handler ]
>The kernel is typically protected by the hardware delaying some
>or all interrupts until the kernel returns control to the user.
>
>For a library routine though, stop and think for a moment.  How
>would you accomplish it?
----

Maybe I'm old fashioned, but I usually mask out signals in critical 
sections, and/or keep status flags to detect errors and reentry... 

I usually use a single signal handler as a dispatcher. This makes 
detection and handling of multiple signals easy.  It is always (in 
the implementations I use) possible to get another (NOT the same 
one) signal in before the handler has a chance to mask it out.
When it is really important, I use semaphores and dispatch queues
to keep it all under control.  That sort of thing usually requires
cooperation from otherwise unrelated parts of the application.


Anyway, the point I want to make is that none of that is new, nor
is any of this:

When a system call is interrupted by a signal, the function returns 
an error status and errno == EINTR.  That is orderly and well 
defined. If you care whether your program works (and sometimes we 
don't), your code must look for error conditions returned from 
system calls. 

Any other library function, however, is the same as any user code. 
It is running in user mode, and may be asynchronously interrupted. 
Such interrupts may occur any old time, not just between source 
lines. That has always been the case, with every architecture and 
compiler that I have ever seen, so this whole issue of global and 
static data being questionable after a longjmp() from a signal 
handler is old hat.

So it's the same old story.  Codification of existing practice and 
all that.  If there is a potential problem, you must design your 
code to deal with it, or live with unreliable programs.  Various 
systems provide variously useful ways of dealing with it.  I don't 
know whether dpANS meddles much with signal control semantics - I 
doubt it. 

-- 
--
	Kent Forschmiedt -- uucp: tikal!camco!happym!kent
	Happy Man Corporation  206-282-9598