Hal Murray <hmur...@megapathdsl.net>:
>
> e...@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>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
