From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq thread safety |
Date: | 2004-01-11 17:45:27 |
Message-ID: | 17158.1073843127@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> + * Used to set callback that prevents concurrent access to
> + * non-thread safe functions that libpq needs.
> + * The default implementation uses a libpq internal mutex.
> + * Only required for multithreaded apps on platforms that
> + * do not support the thread-safe equivalents and that want
> + * to use the functions, too.
> + * List of functions:
> + * - stderror, getpwuid, gethostbyname.
Wait a minute. I am *not* buying into any proposal that we need to
support ENABLE_THREAD_SAFETY on machines where libc is not thread-safe.
We have other things to do than adopt an open-ended commitment to work
around threading bugs on obsolete platforms. I don't believe that any
sane application programmer is going to try to implement a
multi-threaded app on such a platform anyway.
As I said before, I think we should rip out the useless mutex code that
is already there, not introduce a "better" solution to a non-problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Spraul | 2004-01-11 18:11:16 | Re: libpq thread safety |
Previous Message | Manfred Spraul | 2004-01-11 17:33:31 | Re: libpq thread safety |