This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PTHREAD_MUTEX_ERRORCHECK and atfork


[ Sorry, I forgot to CC libc-alpha ]

Jakub Jelinek wrote:
> On Mon, Aug 06, 2007 at 09:26:46AM +0200, Bert Wesarg wrote:
>> Jakub Jelinek wrote:
>>> 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.
>> You say, the posted test program is wrong (beside the notes in some
>> responses)?
> 
> Yes:
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/fork.html
> 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.
> 
> That said, if you ignore that paragraph, pthread_mutex_init
> in the child is the right thing to do with an error checking mutex.
Ok, this part was clear to me. But there is one more sentence in this
paragraph:

Fork handlers may be established by means of the pthread_atfork()
function in order to maintain application invariants across fork() calls.

And this is were we are moving us. Not 'after' fork() but in a atfork
handler in the child. And the ration section there is clear:

The expected usage is that the prepare handler acquires all mutex locks
and the other two fork handlers release them.

What I don't know, if text in the rational describes expected behavior
or if we can ignore this?

Bert

> 
> 	Jakub
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]