Skip site navigation (1) Skip section navigation (2)

Re: SIGCHLD handler in Postgres C function.

From: Bill Studenmund <wrstuden(at)zembu(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, <spshealy(at)yahoo(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SIGCHLD handler in Postgres C function.
Date: 2001-07-30 23:09:03
Message-ID: Pine.NEB.4.33.0107301546590.324-100000@candlekeep.home-net.internetconnect.net (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2001-07-30 23:14:22
Subject: Re: SIGCHLD handler in Postgres C function.
Previous:From: Larry RosenmanDate: 2001-07-30 23:04:53
Subject: Re: Re: OpenUnix 8 Patchj

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group