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.
signature.asc
Description: Digital signature