This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/3] Refactor atfork handlers
On 20/02/2018 10:42, Florian Weimer wrote:
> On 02/20/2018 02:27 PM, Adhemerval Zanella wrote:
>> I think it might occur with proposed implementation only if a callback tries to call
>> pthread_atfork or fork itself. It these scenario you have in mind? And should we
>> really support them if this is the case?
>
> No.
>
> __libc_fork starts like this:
>
> bool multiple_threads
> = THREAD_GETMEM (THREAD_SELF, header.multiple_threads);
>
> __run_fork_handlers (atfork_run_prepare);
>
> And then acquires _IO_list_lock.
>
> I don't see anything which prevents concurrent registration of additional fork handlers between the first and second call to __run_fork_handlers.
The atfork_run_prepare will instruct __run_fork_handlers to take the internal
atfork_lock handler:
void
__run_fork_handlers (enum __run_fork_handler_type who)
{
struct fork_handler *runp;
if (who == atfork_run_prepare)
{
lll_lock (atfork_lock, LLL_PRIVATE);
And it will prevent to add new registration until either the parent or the child
call __run_fork_handlers with either 'atfork_run_child' or 'atfork_run_parent'
to release the lock.
>
> As I said, that shouldn't prevent inclusion of the current patch, but we need to fix this before 2.28, I think.
>
> Thanks,
> Florian