Re: async-signal-safety of chroot

["Trevor Gross" <tg@trevorgross.com>]

On Tue Sep 22, 2026 at 8:34 PM CDT, Rich Felker wrote:
>
> Also, both glibc and musl relax the restriction on only calling
> AS-safe functions in the child after a multi-threaded parent forks. In
> glibc this is sort of a best-effort thing, but in musl we went through
> a detailed process of ensuring that everything is made consistent for
> the child. The only thing that might not be consistent is dynamic
> linker state, which might make it impossible to dlopen in the child,
> but this is treated as a reportable error condition not a crash or
> deadlock or anything.
>
> The changes to lift the restrictions on the child happened in commit
> 167390f05564e0a4d3fcb4329377fd7743267560
>
> Rich

A followup question: the usual wisdom has been that `fork` must always
be followed by an `exec`, and not doing so is somewhere between
error-prone and completely unsound. Based per the commit it sounds like
there are no more deadlocks, and without the POSIX AS-safe requirement,
the soundness question goes away. Does this mean that it is now
considered correct and reasonable code to `fork` without `exec` for the
purpose of e.g. invoking a function in a separate process? Similar to
what can be done with `clone`.

Of course that case may be better served by a way to re-`exec` the same
process for clean state without relying on the exact same hacks, but
that unfortunately doesn't exist.

- Trevor