From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL |
Date: | 2003-11-01 22:25:15 |
Message-ID: | 3FA432CB.1040207@colorfullife.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
>
>
>>What about an option to skip the sigaction calls for apps that can
>>handle SIGPIPE?
>>
>>
>
>If the app is ignoring SIGPIPE globally, then our calls will have no
>effect anyway.
>
Wrong. From the opengroup manpage:
<<
SIG_IGN - ignore signal
[snip]
- Setting a signal action to SIG_IGN for a signal that is pending will
cause the pending signal to be discarded, whether or not it is blocked
<<
This is why the kernel spends 20% cpu time processing the SIG_IGN:
it must walk through all threads of the process and check if there
are any SIGPIPE signals pending.
> I don't see that this proposal adds any security.
>
>
It's not about security: Right now multithreaded apps must call
signal(SIGPIPE, SIG_IGN), otherwise they could get killed by sudden
SIGPIPE signals. Additionally, they can't rely on sigpending, because
the pendings bits are cleared regularly. On top, they get a noticable
performance hit.
My proposal means that apps that know what they are doing (SIGPIPE
either SIG_IGN, or blocked, or a suitable handler) can avoid the
signal(SIGPIPE, SIG_IGN) in pqsecure_write. With backward compatibility,
because the current system works for single threaded apps.
--
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-11-01 22:42:45 | Re: Experimental patch for inter-page delay in VACUUM |
Previous Message | Tom Lane | 2003-11-01 21:37:25 | Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5) |