| 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: | Whole Thread | Raw Message | 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
| 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 |