On 2012/08/15 05:09, Jilles Tjoelker wrote:
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.
Thanks, although SUSv5 will have _Fork(), but application will not catch up.
One solution for this problem is thread library does not execute atfork
handler
when fork() is called from signal handler, but it requires some work to
be done in
thread library's signal wrapper, for example, set a flag that the thread is
executing signal handler, but siglongjmp can mess the flag, so I have
to tweak sigsetjmp and siglongjmp to save/restore the flag, I have such
a patch:
it fetches target stack pointer stored in jmpbuf, and compare it with
top most
stack pointer when a first signal was delivered to the thread, if the
target stack
pointer is larger than the top most stack pointer, the flag is cleared.
_______________________________________________
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"
