Re: SIGCHLD handler in Postgres C function.

On Mon, 30 Jul 2001, Tom Lane wrote:

> Bill Studenmund <wrstuden(at)zembu(dot)com> writes:
> > Looking at source on the web, I found:
>
> > kernel/signal.c:1042
>
> > * Note the silly behaviour of SIGCHLD: SIG_IGN means that the
> > * signal isn't actually ignored, but does automatic child
> > * reaping, while SIG_DFL is explicitly said by POSIX to force
> > * the signal to be ignored.
>
> Hmm, interesting. If you'll recall, the start of this thread was a
> proposal to change our backends' handling of SIGCHLD from SIG_IGN to
> SIG_DFL (and get rid of explicit tests for ECHILD). I didn't quite see
> why changing the handler should make a difference, but above we seem to
> have the smoking gun.
>
> Which kernel, and which version, is the above quote from?

Linux kernel source, 2.4.3, I think i386 version (though it should be the
same for this bit, it's supposed to be MI). Check out
http://lxr.linux.no/source/

I do recall the reason for the thread. :-) I see three choices:

1) Change back to SIG_DFL for normal behavior. I think this will be fine
as we run w/o problem on systems that lack this behavior. If
turning off automatic child reaping would cause a problem, we'd
have seen it already on the OSs which don't automatically reap
children. Will a backend ever fork after it's started?

2) Change to DFL around system() and then change back.

3) Realize that ECHILD means that the child was auto-reaped (which is an
ok think and, I think, will only happen if the child exited w/o
error).

Take care,

Bill