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

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

I wrote:
> 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.

Ah, sorry, I wasn't thinking very clearly there: the mainline would need
to be doing something that takes the RTLD lock exclusively.  Not that
there's any shortage of cases that do that.  Then, if a signal handler
interrupts that and invokes one of the required-to-be-safe libc
functions for the first time in the program, you have a deadlock
in a situation that absolutely should be legal per POSIX.

The Postgres case I started with does not exhibit this, because
we don't do anything in the signals-enabled part of mainline that
would involve an exclusive RTLD lock.  Nonetheless, taking a shared
RTLD lock in a signal handler is clearly a hazard for POSIX compliance,
and this system seems like it will do that in cases that POSIX requires
to be legal.

			regards, tom lane