| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: SIGPIPE handling |
| Date: | 2004-01-08 16:04:45 |
| Message-ID: | 200401081604.i08G4jh15121@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >>
> >>+ /*
> >>+ * We could lose a signal during this test.
> >>+ * In a multi-threaded application, this might
> >>+ * be a problem. Do any non-threaded platforms
> >>
> Threaded or non-threaded?
OK, yea, I will use threaded.
> >>+ * lack sigaction()?
> >>+ */
> >>
> Additionally, the problem is not restricted to multithreaded apps:
> signal(,SIG_IGN) clears all pending signals.
Oh, yuck. Would SIG_DFL be better here? I am thinking of adding
sigblock into that code on the assumption that if they have signal(),
they have sigblock(). Should we disable threaded builds unless they
have sigaction()?
I suppose the sigblock() would take care of the pending signal problem
too.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-01-08 16:53:53 | Re: SIGPIPE handling |
| Previous Message | Claudio Natoli | 2004-01-08 07:33:10 | fork/exec patch: CreateProcess calls for Win32 |