Re: SIGCHLD handler in Postgres C function.

From: Bill Studenmund <wrstuden(at)zembu(dot)com>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <spshealy(at)yahoo(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SIGCHLD handler in Postgres C function.
Date: 2001-07-30 17:37:16
Message-ID: Pine.NEB.4.33.0107271723400.306-100000@candlekeep.home-net.internetconnect.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, 22 Jul 2001, Tatsuo Ishii wrote:

> > spshealy(at)yahoo(dot)com writes:
> > > I have written a postgres C function that
> > > uses a popen linux system call. Orginally when I first tried it I kept
> > > getting an ECHILD. I read a little bit more on the pclose function
> > > and the wait system calls and discoverd that on LINUX if the signal
> > > handler for SIGCHLD is set to SIG_IGN you will get the ECHILD error
> > > on pclose(or wait4 for that matter). So I did some snooping around in
> > > the postgres backend code and found that in the traffic cop that the
> > > SIGCHLD signal handler is set to SIG_IGN. So in my C function right
> > > before the popen call I set the signal handler for SIGCHLD to SIG_DFL
> > > and right after the pclose I set it back to SIG_IGN. I tested this
> > > and it seems to solve my problem.

Just ignore ECHILD. It's not messy at all. :-) It sounds like your kernel
is using SIG_IGN to do the same thing as the SA_NOCLDWAIT flag in *BSD
(well NetBSD at least). When a child dies, it gets re-parrented to init
(which is wait()ing). init does the child-died cleanup, rather than the
parent needing to. That way when the parent runs wait(), there is no
child, so you get an ECHILD.

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.

Take care,

Bill

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mikheev, Vadim 2001-07-30 17:45:30 RE: Performance TODO items
Previous Message Bruce Momjian 2001-07-30 17:30:29 Re: Revised Patch to allow multiple table locks in "Unison"