Re: [PATCH 3/3] Refactor atfork handlers

[Florian Weimer <fweimer at redhat dot com>]

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.

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