This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] malloc: Remove malloc hooks from fork handler
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 19 Feb 2016 17:32:09 +0100
- Subject: Re: [PATCH] malloc: Remove malloc hooks from fork handler
- Authentication-results: sourceware.org; auth=none
- References: <56BBB02E dot 5020906 at redhat dot com> <1455556066 dot 20971 dot 1 dot camel at localhost dot localdomain>
On 02/15/2016 06:07 PM, Torvald Riegel wrote:
> LGTM with one question.
>
> On Wed, 2016-02-10 at 22:48 +0100, Florian Weimer wrote:
>> @@ -206,63 +137,30 @@ static unsigned int atfork_recursive_cntr;
>> void
>> __malloc_fork_lock_parent (void)
>> {
>> - mstate ar_ptr;
>> -
>> if (__malloc_initialized < 1)
>> return;
>>
>> /* We do not acquire free_list_lock here because we completely
>> reconstruct free_list in __malloc_fork_unlock_child. */
>>
>> - if (mutex_trylock (&list_lock))
>> - {
>> - if (thread_arena == ATFORK_ARENA_PTR)
>> - /* This is the same thread which already locks the global list.
>> - Just bump the counter. */
>> - goto out;
>> + (void) mutex_lock (&list_lock);
>
> Is it obvious why the recursive case that the previous code tried to
> handle can't happen anymore? If not, a comment might be useful.
I think it is obvious with the previous change (which runs the fork
handler as late as possible).
The opposite was actually trueâit's hard to see why the recursive lock
was ever needed because the need depended on fork handler ordering.
Thanks,
Florian