Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not really: it only solves the problem *if you change the application*,
>> which is IMHO not acceptable.
> No. non-threaded apps do not need to change. The default is the old, 7.3
> code: change the signal handler around the write calls. Which means that
> non-threaded apps are guaranteed to work without any changes, regardless
> of the libpq thread safety setting.
Hmm, so you propose that a thread-enabled library must contain both code
paths and choose between them on the fly? That seems like the worst of
all possible worlds --- it's not backwards compatible, it's therefore
unsafe, it's slow, *and* it'll be #ifdef hell to read.
On a platform that has pthread_sigmask, ISTM we can use that
unconditionally and it'll work whether the calling app is threaded or
not. We only fall back to the pqsignal method if we aren't supporting
threads. There's no need for a runtime test nor for an API change.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
