On Thu, Jun 14, 2001 at 04:27:14PM -0400, Tom Lane wrote:
> ncm@zembu.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.
Quoting Stevens (UNPv2, p. 90),
Posix uses the term *async-signal-safe* to describe the functions that may be called from a signal handler. Figure
5.10lists these Posix functions, along with a few that were added by Unix98.
Functions not listed may not be called from a signal andler. Note that none of the standard I/O functions ... are
listed. Of call the IPC functions covered in this text, only sem_post, read, and write are listed (we are assuming the
lattertwo would be used with pipes and FIFOs).
Restricting the handler to use those in the approved list seems like an
automatic improvement to me, even in the apparent absence of evidence
of problems on those platforms that happen to get tested most.
> > A pipe per backend might be considered pretty expensive.
>
> Pipe per postmaster, no? That doesn't seem like a huge cost.
I haven't looked at how complex the signal handling in the backends is;
maybe they don't need anything this fancy. (OTOH, maybe they should be
using a pipe to communicate with postmaster, instead of using signals.)
> I'd be
> more concerned about the two extra kernel calls (write and read) per
> signal received, actually.
Are there so many signals flying around? The signal handler would check
a flag before writing, so a storm of signals would result in only one
call to write, and one call to read, per select loop.
Nathan Myers
ncm@zembu.com
