On Mon, Feb 05, 2007 at 11:09:06AM -0500, Tom Lane wrote:
> I think the real point is that you get the same C library whether you
> ask for thread safety or not, and it does internal locking to protect
> itself against multi threads anyway. So arguably there's no point in
> building a thread-unsafe version of libpq.
The underlying issue is that there is no way to be sure a program will
not have threads. Just because you didn't compile against pthreads,
don't mean there won't be any threads. An example being a
gethostbyname() that loads a threaded version of an LDAP library, for
example.
For programs it doesn't matter, but for shared-libraries you never know
whether you're going to be called from the main thread of execution or
not, and if you're not you're buggered.
> But having said that, 99.99% of Linux use is based on pre-built RPMs,
> and the RPM packagers all understand how to make this decision, so
> it's really not our problem to fix.
That's true, but I think it would be worthwhile to invert the switch to
be --disable-thread-safety, since the number of people who don't
understand the problem far outweigh the cost of the switch.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.