"Tom Lane" <[EMAIL PROTECTED]> writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Guys, too much thought is being spent on this...
> > 1. For the _r functions we "need" we should ALWAYS use them if the
> > system we are building on has them - they WILL be thread-safe.
>
> > 2. If the system is missing a _r function then we implement a wrapper
> > to call the normal non-_r version. However we do NOT make this wrapper
> > call thread-safe - we assume the non-_r version already is.
>
> That assumption is exactly what Peter is unhappy about. With the above
> approach we will happily build a "thread safe" library on systems that
> are in fact not thread safe at all. Peter wants --enable-thread-safety
> to fail on non-safe systems.
Yeah, I see that as Peter's main objection too. But it really isn't worth
the
trouble, on such systems a user's app will be so horribly broken WRT
threads anyway. It isn't our job to point out the shortcomings of their
system.
Really such systems don't exist - if libc doesn't have _r calls and the
traditional ones are not thread-safe then do you think it'll have a
threading
library which can run >1 thread concurrently?
On such a system the users troubles will start long before PostgreSQL
if they play with threads.
L.
---------------------------(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
