This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] nptl: Avoid fork handler lock for async-signal-safe fork [BZ #24161]
On 04/02/2019 18:33, Florian Weimer wrote:
> * Adhemerval Zanella:
>> Now it has bitten us again, how should we proceed to handle async-safeness
>> for fork? Should we add signal handler wrapper so we can detect if fork
>> is called in a signal handler and handle the locks properly? Or should
>> we follow Rich suggestion in comment #21 at BZ#4737 and use a recursive
>> and reentrant lock?
> For what? This particular lock, or all potentially relevant locks? The
> list of locks we'd need to fix is quite long.
My questioning was to make fork async-signal-safe for the generic way, not only
for single-thread as we currently aim to. Another question is whether we really
care to make fork async-signal-safe in all possible context, more specially
in multithread environments.
> I think it's more promising to eliminate locks through STM techniques
> and also provide async-signal-safety this way.
There is an option I haven't considered yet. Not sure if it would be easier
to fix the reentracy issue with fork.
>> I would prefer if handle it on fork instead, since the logic and requirement
>> of locking depends on how we define the fork semantics regarding atfork
>> handlers (and it already handler other locks in same manner).
> Do you suggest to expose the lock as a global variable, and lock and
> unlock it in the fork implementation, as appropriate? I'm not sure if
> that's an improvement.
Thinking again, you are right. I will review the original patch.