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

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

Robert Elz <kre%munnari.OZ.AU@localhost> writes:
>    |  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.

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.

POSIX forgot to specify that that's not okay, because who would think
you need to mention it?  They certainly aren't going to write down
that addition is async-signal-safe, for example; but there's nothing
in either POSIX or the C standard that distinguishes some bare-C
operations from others.  Indeed, depending on platform and data type
involved, I wouldn't be too surprised if addition is sometimes *not*
async-signal-safe on NetBSD 10.  Which nominally-primitive C operations
get implemented by calls to libgcc_s.so?

I also suspect that it's possible to construct examples that violate the
explicit letter of the POSIX spec, in that they list a bunch of functions
that are required to be async-signal-safe but are in libc.so and therefore
require RTLD resolution before the first call.  Consider, say, select()
in the mainline, and while we're resolving that we get an interrupt and
the signal handler tries to invoke lseek() and that requires resolution.
I'm failing to see how the resulting deadlock is allowed per POSIX.

Anyway, linking with "-z now" solves this problem sufficiently for my
purposes.

			regards, tom lane