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

[David Holland <dholland-bugs%netbsd.org@localhost>]

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

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/56979: fork(2) fails to be signal safe
Date: Sun, 28 Aug 2022 19:52:22 +0000

 On Sun, Aug 28, 2022 at 05:05:01PM +0000, Tom Lane wrote:
  > I think Taylor's fix may still be a good idea for pro-forma spec
  > compliance, but I despair of getting to a reliable Postgres build
  > this way.  (BTW, is the RTLD lock business new in v10?  I'm
  > surprised that we've not heard field reports of Postgres getting
  > stuck at startup on NetBSD.)
 
 I don't think so; no idea why it would have broken now.
 
 The expedient path may be to use posix_spawn instead of fork; it's
 kernel-level on netbsd so the various specific issues that pthreads
 causes with fork disappear.
 
  >  What I'm wondering about now is whether there is a way to force resolution
  >  of that PLT entry, or even all of the program's PLT entries, before we
  >  enable signals.  If there are multiple select(2) calls in the same source
  >  file, will they share a PLT entry?  If so, I could arrange to run a dummy
  >  select() call somewhere early in startup.
 
 There's LD_BIND_NOW, but I'm not sure if there's a good way to request
 that behavior from inside a program :-(
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost