Re: What (not) to do in signal handlers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ncm(at)zembu(dot)com (Nathan Myers) writes:
> > 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.)
> > Of course this is still a system call in a signal handler, but it can't
> > (modulo coding bugs) fail.
>
> Hm. That's one way, but is it really any cleaner than our existing
> technique? Since you still need to assume you can do a system call
> in a signal handler, it doesn't seem like a real gain in
> bulletproofness to me.

Doing write() in a signal handler is safe; doing fprintf() (and
friends) is not. POSIX specifies async-signal-safe functions, of
which write() is one. I'd be very surprised if any Unix that people
are using today had reentrancy problems with write(). All bets are
off with fprintf() and the other stdio functions--they are not
guaranteed async-signal-safe, and production code should never call
them in a signal handler. Stevens is very thorough on this subject.

> > A pipe per backend might be considered pretty expensive.
>
> Pipe per postmaster, no? That doesn't seem like a huge cost. I'd be
> more concerned about the two extra kernel calls (write and read) per
> signal received, actually.

That's definitely an issue, but signals are (generally) pretty rare
beasts, unless you're doing signal-driven I/O or some such.

-Doug
--
The rain man gave me two cures; he said jump right in,
The first was Texas medicine--the second was just railroad gin,
And like a fool I mixed them, and it strangled up my mind,
Now people just get uglier, and I got no sense of time... --Dylan