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 | 3FA7FC83.1010008@colorfullife.com обсуждение исходный текст |
Ответ на | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 (markw@osdl.org) |
Ответы |
Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5
|
Список | pgsql-hackers |
markw@osdl.org wrote: >On 1 Nov, Tom Lane wrote: > > >>Manfred Spraul <manfred@colorfullife.com> writes: >> >> >>>signal handlers are a process property, not a thread property - that >>>code is broken for multi-threaded apps. >>> >>> >>Yeah, that's been mentioned before, but I don't see any way around it. >>What we really want is to turn off SIGPIPE delivery on our socket >>(only), but AFAIK there is no API to do that. >> >> > >Will this be a problem for multi-threaded apps with any of the client >interfaces? > >Anyone working on making it threadsafe? > > The POSIX api is not thread safe: signal handlers are per process, and libpq would like to block SIGPIPE for it's send() calls. For single threaded apps, libpq just calls sigaction and sets the handler to SIG_IGN around the syscalls. For multithreaded apps, this is not possible: sigaction is per process. Thus the calling application must handle the SIGPIPE signals for libpq - either by blocking or ignoring them. We are still discussing the exact API. Probably a global state that is accessible through a new function. One thread-safe alternative might be the combination of sigprocmask / pthread_sigmask and sigwait, but I think this would be too fragile. -- Manfred
В списке pgsql-hackers по дате отправления: