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

Поиск
Список
Период
Сортировка
От Manfred Spraul
Тема Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL
Дата
Msg-id 3FA432CB.1040207@colorfullife.com
обсуждение исходный текст
Ответ на Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL
Список pgsql-hackers
Tom Lane wrote:

>Manfred Spraul <manfred@colorfullife.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
timeprocessing the SIG_IGN:   it must walk through all threads of the process and check if there   are any SIGPIPE
signalspending.
 

>  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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Avoiding SIGPIPE (was Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5)
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: Experimental patch for inter-page delay in VACUUM