Re: [PATCH 3/3] Refactor atfork handlers

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 20/02/2018 10:05, Florian Weimer wrote:
> 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.

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?


> 
>> 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.
>