This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PTHREAD_MUTEX_ERRORCHECK and atfork
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Bert Wesarg <wesarg at informatik dot uni-halle dot de>
- Cc: libc-alpha at sourceware dot org
- Date: Sun, 5 Aug 2007 21:35:44 +0200
- Subject: Re: PTHREAD_MUTEX_ERRORCHECK and atfork
- References: <59184.87.193.53.152.1186340831.squirrel@merkur.informatik.uni-halle.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sun, Aug 05, 2007 at 09:07:11PM +0200, Bert Wesarg wrote:
> a user has posted[1] a problem to the comp.programming.threads group, that
> he get EPERM errors in a child atfork handler from a pthread_mutex_unlock
> with an error checking mutex.
That's correct, the child doesn't contain the thread that locked the mutex
(although pthread_self () in the child may return the same value as in the
parent, those identifiers are only unique within each process), it contains
a different thread, so calling pthread_mutex_unlock in the child is wrong.
It is wrong for multiple reasons, e.g. pthread_mutex_unlock is not an
async-signal-safe routine and in the child after fork you can only call
async-signal-safe routines until one of the exec family functions succeeds
or the process exits.
Jakub