questions about bug 4737 (fork is not async-signal-safe)
Jonathan Nieder
jrnieder@gmail.com
Wed May 11 03:05:00 GMT 2011
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
More information about the Libc-help
mailing list