Re: fork-like functions and async-signal-safety

On Fri, Dec 01, 2023 at 09:26:51AM -0700, Alan Somers wrote:
> fork() is not async-signal-safe, and therefore can't be used in a
> signal handler.
... if the process is multithreaded.

> Nor can it be used from a multithreaded program
> (unless the child only executes aysnc-signal-safe functions).
More precisely, it is not guaranteed to work in the child of the fork of
mt process.  I believe (with high confidence) that it works for the
FreeBSD implementation.

> 
> _Fork(), OTOH, is async-signal-safe.  According to fork(2), "It can be
> used safely from signal handlers, but then no userspace services
> (malloc(3) or rtld(1)) are available in the child if forked from
> multi-threaded parent."
> 
> But can you use malloc and rtld in the child if _Fork was invoked from
> a multi-threaded process, but not from a signal handler?  That's not
> clear to me.
No.

> 
> And what about pdfork?  Neither sigaction(2) nor pdfork(2) specify
> whether pdfork is async-signal-safe.  Is it?
pdfork() is same as fork().

> 
> FYI the reason I'm asking is that I'm trying to determine whether it
> would be possible to make cap_init() async-signal-safe.