Re: questions about bug 4737 (fork is not async-signal-safe)

[Jonathan Nieder <jrnieder at gmail dot com>]

Hi Norbert,

Norbert van Bolhuis wrote:

> The reason is I'm running into the corrupted _IO_list_all
> problem for some of our application threads that use system(3)
> (which is implemented with fork + exec).

POSIX.1-2008 does not list system as an async-signal-safe function.
But that should not be relevant here:

> I believe it is caused by our application that can stop
> the threads asynchronously by using pthread_cancel.
> Note that libc implements pthread_cancel by sending a
> SIGCANCEL (signr=32) with tkill.

One only needs to worry about whether a function is async-signal-safe
if planning to use it from within a signal handler.  

So let's look for other explanations.  Are you saying your threads use
the asynchronous cancellability type?  If I am reading the standard
correctly then the only functions guaranteed safe to use in such a
thread are pthread_cancel(), pthread_setcancelstate(), and
pthread_setcanceltype().

>  well at least my signal(7) man page says fork is async-signal-safe)

That's true.  Current POSIX requires fork to be async-signal-safe.  It
will probably change with issue 8 of the standard; see
http://austingroupbugs.net/view.php?id=62 for some details.

> Is this bug solved in the latest glibc ?

I don't know.  I'd suggest trying and seeing. :)

Thanks and hope that helps,
Jonathan