This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: questions about bug 4737 (fork is not async-signal-safe)
- From: Jonathan Nieder <jrnieder at gmail dot com>
- To: Norbert van Bolhuis <nvbolhuis at aimvalley dot nl>
- Cc: libc-help at sourceware dot org
- Date: Tue, 10 May 2011 22:04:38 -0500
- Subject: Re: questions about bug 4737 (fork is not async-signal-safe)
- References: <4DC94C42.4040907@aimvalley.nl>
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