This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix possible deadlock in stdio locking code
- From: Jonathan Nieder <jrnieder at gmail dot com>
- To: Siddhesh Poyarekar <spoyarek at redhat dot com>
- Cc: Andreas Schwab <schwab at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 11 Nov 2011 03:09:40 -0600
- Subject: Re: [PATCH] Fix possible deadlock in stdio locking code
- References: <20111018140922.GA5701@spoyarek.pnq.redhat.com><m3vcrmgxcc.fsf@hase.home><20111107123054.GA9524@spoyarek.redhat.com>
Siddhesh Poyarekar wrote:
> while(1) {
> int child = fork();
>
> if (child == 0)
> exit(0);
POSIX explains (under fork()):
If a multi-threaded process calls fork( ), the new process
shall contain a replica of the calling thread and its entire
address space, possibly including the states of mutexes and
other resources. Consequently, to avoid errors, the child
process may only execute async-signal-safe operations until
such time as one of the exec functions is called.
exit() is not async-signal-safe, though _exit() is. I don't think
that glibc is the right tool to diagnose or work around application
problems like this. (Maybe helgrind could be tweaked to make the
diagnosis.)