This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/3] Refactor atfork handlers

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]