On 03/08/2011 11:00 AM, Andreas Schwab wrote: > "Dr. Werner Fink" <wer...@suse.de> writes: > >> On Tue, Mar 08, 2011 at 12:02:53PM -0500, Chet Ramey wrote: >>>> >>>> Does this mean that the attached patch could also not work >>>> on some systems? Or does this interfere with the readline >>>> library? >>> >>> Since longjmp is not on the list of functions that is safe to call >>> from a signal handler, yes, that's what it means. OTOH, this shows >>> promise as a solution. >> >> OK, that means only for systems with HAVE_POSIX_SIGSETJMP >> defined. At least this provides a (local) solution here > > sigsetjmp is the same as setjmp. Both will lead to deadlocks.
sigsetjmp is safe to call from a signal handler _if_ you are in the handler because of a synchronous signal (such as one generated internally by raise(), and not generated externally and asynchronously by kill()), or if you can prove that it was not interrupting any other non-async-signal-safe function (however, blocking all signals around all calls to non-async-signal-safe functions is very inefficient). But deadlock is indeed possible if an asynchronous SIGHUP occurs while the malloc() lock is held (if you try to malloc() in the cleanup code, but siglongjmp() left the middle of earlier code that already held the malloc() lock, then you indeed have deadlock). Which is why POSIX does not list siglongjmp() as an async-signal-safe function, because after siglongjmp(), you are generally only safe to invoke async-signal-safe functions, which is no better than invoking those same functions directly within the signal handler itself in the first place. Really, the only safe way to handle things like SIGHUP cleanup is to have the signal handler record that an exception occurred, then have the main processing loop checking that variable frequently enough to do cleanup in a reasonable time-frame (possibly by using a pipe-to-self if the main loop is waiting on select()), where the main loop then re-raises the signal after doing cleanup at a point where all functions are safe. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature