system() using vfork() or posix_spawn() and libthr

[David Xu]

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.