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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Tom Lane <tgl%sss.pgh.pa.us@localhost>
Cc: lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Sun, 16 Oct 2022 15:18:58 +0700

     Date:        Sat, 15 Oct 2022 22:46:52 -0400
     From:        Tom Lane <tgl%sss.pgh.pa.us@localhost>
     Message-ID:  <1628442.1665888412%sss.pgh.pa.us@localhost>
 
   | Well, here is the actual problem: with this implementation, the mere
   | act of invoking a C function is not guaranteed to be async-signal-safe,
   | depending on whether it crosses a not-terribly-well-defined linkage
   | boundary.
 
 For that I'd agree, it should be possible to call any async signal safe
 function from within a signal handler, regardless of where the signal
 occurs, and if that isn't working for us, we should fix that.
 
 But the stack trace that Taylor showed in his message had the signal handler
 calling dlopen() - that's linking to a whole new library (loading a new
 external file).   That is certainly not async signal safe.
 
 kre