| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: SIGPIPE handling, take two. |
| Date: | 2003-11-11 17:28:12 |
| Message-ID: | 10059.1068571692@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> What about multithreaded apps?
> old = pgsignal(SIPEPIPE, SIG_IGN);
> ** another thread calls sigaction(SIGPIPE,,);
> pgsignal(SIGPIPE, old);
> And the signal state is corrupted.
If other threads are changing the signal state mid-flight, we are
screwed anyway; if not here then later when we are doing sends,
or even more directly because our test here may not reflect reality
later.
I don't think we need to complicate pqsignal's API for this. Instead
we'd better document that SIGPIPE handling has to be set up and kept
stable before doing any libpq operations in a multithread app.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Manfred Spraul | 2003-11-11 17:37:52 | Re: SIGPIPE handling, take two. |
| Previous Message | Manfred Spraul | 2003-11-11 17:22:45 | Re: SIGPIPE handling, take two. |