Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
От | Manfred Spraul |
---|---|
Тема | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 |
Дата | |
Msg-id | 3FA3FAF5.8020602@colorfullife.com обсуждение исходный текст |
Ответ на | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 |
Список | pgsql-hackers |
Tom Lane wrote: >Manfred Spraul <manfred@colorfullife.com> writes: > > >>Is that really necessary? >> >> > >Unfortunately, yes. libpq can't change the global setting of SIGPIPE >without breaking the surrounding application, but we don't want to crash >the app if the server connection has disappeared, either. So we have to >set the SIGPIPE handler and then restore it around every send(). > > Ok. Ahm. No, wait. libpq is multi-threaded, right? signal handlers are a process property, not a thread property - that code is broken for multi-threaded apps. At least that's how I understand the opengroup man page, and a quick google confirmed that: http://groups.google.de/groups?selm=353662BF.9D70F63A%40brighttiger.com I haven't found a reliable thread-safe approach yet: My first idea was block with pthread_sigmask, after send check if pending with sigpending, and then delete with sigwait, and restore blocked state. But that breaks if SIGPIPE is blocked and a signal is already pending: there is no way to remove our additional SIGPIPE. I don't see how we can avoid destroying the realtime signal info. Mark: Is your dbt2 testapp multithreaded? I don't see the signal functions near the top in the profiles on the osdl website. -- Manfred
В списке pgsql-hackers по дате отправления: