What is GLibc's policy on what is safe to use after a fork from a multithreaded program?

[Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>]

Hello,

POSIX conformance constrains one to only use async-signal-safe
functions after a fork from a mulithreaded program.  More practically,
fork fucks with state such as the PID, pending signals, timers,
outstanding asynchronous I/O operations and locks that threads are
holding onto.  I need to fork from a multithreaded program and do
complicated things such as sandboxing a process with non
async-signal-safe functions such as mount, syscall, unshare, umount2
and setgroups (I can't exec a helper process because that drops
capabilities automatically).  I can always check the GLibc source and
verify if problems will happen but that becomes really painful when
checking all the system calls I use.  As well, in the future GLibc can
always change functions to be not safe after a fork from a
multithreaded program.  What is GLibc's policy on what is safe to use
after a fork from a multithreaded program?  There doesn't seem to be
any documentation about this.

Thank you,
Steven Stewart-Gallus