Re: [PATCH 3/3] Refactor atfork handlers

[Florian Weimer <fweimer@redhat.com>]

On 02/20/2018 02:00 PM, Adhemerval Zanella wrote:
> The temporary copy is problematic because we either need to allocate on the stack using
> vla/alloca (current practice and prone of stack overflow) or by malloc (which requires
> locking anyway).  Also, to temporary copy we will need pretty much the same lock-free
> algorithm which adds code complexity.

I think the lock in malloc is fine, at least for the time being, with 
our non-async-safe fork.

The point is not avoiding the lock, but callbacks when the lock is held. 
  This can easily result in deadlocks.

> My understanding is current algorithm tries hard to remove any locking on fork generation
> mainly because back then posix_spawn was no specified and suboptimal. Now that we have
> a faster way to spawn process in multithread environment I think there is no much gain
> in trying to optimizing locking in atfork handlers.

I think it's also needed to avoid deadlocks .

> Regarding the handler running in child process the proposed implementation does implement
 > it.

I don't see how?  I meant that only those handlers run that ran in the 
parent.  I think there's a window where more fork handlers can be added.

Thanks,
Florian