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]
* 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.
I think it's more promising to eliminate locks through STM techniques
and also provide async-signal-safety this way.
> 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.