Re: SIGCHLD handler in Postgres C function.

On Mon, 30 Jul 2001, Tom Lane wrote:

> Bill Studenmund <wrstuden(at)zembu(dot)com> writes:
> > All ECHILD is doing is saying there was no child. Since we aren't really
> > waiting for the child, I don't see how that's a problem.
>
> You're missing the point: on some platforms the system() call is
> returning a failure indication because of ECHILD. It's system() that's
> broken, not us, and the issue is how to work around its brokenness
> without sacrificing more error detection than we have to.

I think I do get the point. But perhaps I didn't make my point well. :-)

I think the problem is that on some OSs, setting SIGCHLD to SIG_IGN
actually triggers automatic child reaping. So the problem is that we are:
1) setting SIGCHLD to SIG_IGN, 2) Calling system(), and 3) thinking ECHILD
means something was really wrong.

I think 4.4BSD systems will do what we expect (as the NO_CHLDWAIT flag
requests child reaping), but linux systems will give us the ECHILD.
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.

So we get automatic reaping on Linux systems (which isn't bad).

If automatic reaping happens, system will give us an ECHILD as the waitpid
(or equivalent) will not have found a child. :-)

My suggestion is just leave the ifs as "if ((error == 0) || (error ==
ECHLD))" (or the inverse).

Take care,

Bill