SIGINT, longjmp

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > I don't know of any functions that are specifically unsafe around setjmp()/
> > longjmp().
> 
> The interesting case is longjmp-ing from a signal handler.

Right.  I believe the way a signal handler works is actually like a
setjmp/longjmp; that is, on receipt of a signal the register contect
is saved, the handler is called, then on exit the register context is
restored.

It probably does follow that you don't want to longjmp() out of a signal
handler; hidden context like signal block masks mightnot be restored.
I note that the GPSD code does not do this.  I think I used to know details
about this that I've forgotten.

> > The right way to think about setjmp()/longjmp() is as a save/restore of the
> > processor's register state, including  the stack and frame pointers.  It
> > doesn't have the concurrency issues that threads do because it doesn't alter
> > static memory or the heap.
> 
> It doesn't alter the heap, but it doesn't restore it either.

Correct.

> Anything that calls malloc is an opportunity for a storage leak.  Jmp-ing 
> from a signal handler yanks you out of the middle of a routine without any 
> opportunity for cleanup.

Correct.

> I suspect getaddrinfo masks or intercepts SIGINT, but I haven't found 
> anything like that in the man pages.  The symptom is that ^C doesn't work 
> right away but does work after several seconds, a reasonable time for a DNS 
> lookup if you need to retransmit or have a bloated link.

Ah, it's probably doing a sigsuspend(2).
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>