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 по дате отправления: