Re: What (not) to do in signal handlers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: What (not) to do in signal handlers
Date: 2001-06-14 20:27:14
Message-ID: 21586.992550434@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Pilosov 2001-06-14 20:30:14 [PATCH] indexability of << operator for inet/cidr
Previous Message Bruce Momjian 2001-06-14 20:17:36 Re: Removal of temp tables