Re: lib/56979: fork(2) fails to be signal safe

[Joerg Sonnenberger <joerg%bec.de@localhost>]

The following reply was made to PR lib/56979; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost
Subject: Re: lib/56979: fork(2) fails to be signal safe
Date: Fri, 26 Aug 2022 00:16:48 +0200

 Am Thu, Aug 25, 2022 at 04:30:00PM +0000 schrieb tgl%sss.pgh.pa.us@localhost:
 > >Fix:
 > Is there a way to not need the RTLD lock during fork()?
 
 Depending on what you want to do, you can use __fork() directly. That
 skipps the locking, but also e.g. pthread_atfork(3).
 
 At this point, I have mostly given up on async signal safety for
 fork(2). On the one hand, way too many programs and libraries nowadays
 expect fork from multi-threaded progams to give a mostly usable state
 (e.g. beyond "I can run exec now"). Then you have all the work fork()
 has to do beyond being a simple system call (the traditional members of
 the async signal safe list all are). E.g. pthread_atfork has to be
 written to be atomic regarding any interruption by a signal handler.
 
 Joerg