Re: Avoiding SIGPIPE (was Re: [HACKERS] OSDL DBT-2 w/ PostgreSQL

[Manfred Spraul]

Tom Lane wrote:

Manfred Spraul <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster