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: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Sun, 16 Oct 2022 08:51:14 +0700

     Date:        Sun, 16 Oct 2022 01:20:01 +0000 (UTC)
     From:        Tom Lane <tgl%sss.pgh.pa.us@localhost>
     Message-ID:  <20221016012001.C22DB1A9239%mollari.NetBSD.org@localhost>
 
   |  Well, it *was* a signal handler, but once it issues fork() I wouldn't
   |  personally regard it as a signal handler anymore.
 
 Sorry, but that is utter nonsense.
 
   |  The child process
   |  is certainly never going to return control to the interrupted code.
 
 Your child process might not, but someone else's might.   Neither the
 system, nor the libraries, can assume that it will not.
 
 There is not, and never has been, any rule that says what code can be
 run in the parent or child returns from fork().
 
   |  The postmaster has been coded like that since the  nineties,
 
 Then it has been broken since then.
 
   | and AFAIR this is the first bit of trouble we've had with it.
 
 That may be true, but "I tried it and it worked, even though the
 rules say I shouldn't do that" has never been a good excuse for
 anything.
 
 The next time you get pulled over for drink driving, try telling the
 police/courts that you've been doing it since the 90's, and never had
 any trouble before, see how far that gets you.
 
 You break the rules, things don't go as you'd hoped they would, it is
 your fault, this time and every time.
 
 Call anything that is not async signal safe in a signal handler, or fail
 to have shared variables correctly marked as volatile, and anything might
 happen.   That it doesn't happen today, doesn't mean that it won't tomorrow.
 
 kre