On Tue, Feb 18, 2014 at 11:43:10AM +0100, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> writes: > > > Il 18/02/2014 11:05, Markus Armbruster ha scritto: > >>> > Yes, SIGABRT is synchronous for all purposes. So the only danger is > >>> > that g_string_free() or g_free() could fail while we're in > >>> > g_assert(false). But they don't, which makes sense because they are > >>> > totally unrelated to g_assert() and therefore can handle re-entrancy. > >> The (theoretical!) problem is when it aborts in the bowels of g_*free(), > >> and your SIGABRT handler reenters g_*free(). > >> > >>> > In practice there is no issue and I've tested assertion failure with > >>> > glib 1.2.10. > >> Worst that can happen is we crash on the way from abort() to process > >> termination. Tolerable. > > > > What about recursive locking of a non-recursive mutex? > > You're right, deadlock is possible. Strengthens the argument for: > > >> Still, avoiding unnecessary cleanup on that path seems prudent to me. > >> If you agree, factor out the kill()/waitpid(), and call only that from > >> the signal handler.
Okay, I'm convinced.
