Re: What (not) to do in signal handlers

On Thu, Jun 14, 2001 at 02:18:40PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > I notice that the signal handlers in postmaster.c do quite a lot of work,
> > much more than what they teach you in school they should do.
>
> Yes, they're pretty ugly. However, we have not recently heard any
> complaints suggesting problems with it. Since we block signals
> everywhere except just around the select() for new input, there's not
> really any risk of recursive resource use AFAICS.
>
> > ISTM that most of these, esp. pmdie(), can be written more like the SIGHUP
> > handler, i.e., set a global variable and evaluate right after the
> > select().
>
> I would love to see it done that way, *if* you can show me a way to
> guarantee that the signal response will happen promptly. AFAIK there's
> no portable way to ensure that we don't end up sitting and waiting for a
> new client message before we get past the select().

It could open a pipe, and write(2) a byte to it in the signal handler,
and then have select(2) watch that pipe. (SIGHUP could use the same pipe.)
Writing to and reading from your own pipe can be a recipe for deadlock,
but here it would be safe if the signal handler knows not to get too far
ahead of select. (The easy way would be to allow no more than one byte
in the pipe per signal handler.)

Of course this is still a system call in a signal handler, but it can't
(modulo coding bugs) fail. See Stevens, "Unix Network Programming,
Vol. 2, Interprocess Communication", p. 91, Figure 5.10, "Functions
that are async-signal-safe". The figure lists write() among others.
Sample code implementing the above appears on page 94. Examples using
other techniques (sigwait, nonblocking mq_receive) are presented also.

A pipe per backend might be considered pretty expensive. Does UNIX
allocate a pipe buffer before there's anything to put in it?

Nathan Myers
ncm(at)zembu(dot)com