From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
---|---|
To: | markw(at)osdl(dot)org |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, osdldbt-general(at)lists(dot)sourceforge(dot)net |
Subject: | Re: OSDL DBT-2 w/ PostgreSQL 7.3.4 and 7.4beta5 |
Date: | 2003-11-04 19:22:43 |
Message-ID: | 3FA7FC83.1010008@colorfullife.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
markw(at)osdl(dot)org wrote:
>On 1 Nov, Tom Lane wrote:
>
>
>>Manfred Spraul <manfred(at)colorfullife(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | kgleason | 2003-11-04 19:32:24 | Re: Hacking PostgreSQL to work in Mac OS X 10.3 (Panther 7B85) |
Previous Message | Joshua D. Drake | 2003-11-04 19:14:33 | Open Sourcing pgManage |