On Tue, Aug 14, 2012 at 11:15:06PM +0800, David Xu wrote: > But in real word, pthread atfork handlers are not async-signal safe, > they mostly do mutex locking and unlocking to keep consistent state, > mutex is not async-signal safe. > The malloc prefork and postfork handlers happen to work because I have > some hacking code in library for malloc locks. Otherwise, you even > can not use fork() in signal handler.
This problem was also reported to the Austin Group at http://austingroupbugs.net/view.php?id=62 Atfork handlers are inherently async-signal-unsafe. An interpretation was issued suggesting to remove fork() from the list of async-signal-safe functions and add a new async-signal-safe function _Fork() which does not call the atfork handlers. This change will however not be in POSIX.1-2008 TC1 but only in the next issue (SUSv5). A slightly earlier report http://austingroupbugs.net/view.php?id=18 just requested the _Fork() function because an existing application deadlocked when calling fork() from a signal handler. -- Jilles Tjoelker _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
