Philip Yarra <philip@utiba.com> writes:
> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>> Tom Lane wrote:
>>> It doesn't seem to me that we should take on the job of providing
>>> thread-safe implementations of basic libc functions. If a particular
>>> OS cannot manage to offer that functionality, then we should mark it
>>> not-thread-safe and move on.
> This would be a pretty short list unless I count wrong!
If it's a short list, then it's a short list.
> Surely the development of PostgreSQL has seen lots of platform shortcomings
> found and worked-around? Why not this as well?
Because we are not working in a vacuum. A thread-safe implementation of
libpq is of zero value to an application unless it also has thread-safe
implementations of the other libraries it depends on. When the
platform's libc has more thread-safety holes than the average block of
swiss cheese, there is no reason that I can see for us to expend effort
on workarounds that only fix libpq's usage. Any app that might want to
use libpq is going to hit those same bugs, and so in the long run the
only useful answer is for the platform to fix its libc.
The real bottom line here is: who is going to try to build threaded
apps on platforms with un-thread-safe libc? And why should we be the
ones to try to save them from suffering the pain they deserve? We have
enough problems of our own to deal with...
regards, tom lane