Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) - Mailing list pgsql-hackers

From Lee Kindness
Subject Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
Date
Msg-id 002401c370cb$9e6643c0$1f90e150@coulter
Whole thread Raw
In response to Re: Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)  (Kurt Roeckx <Q@ping.be>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Lee Kindness <lkindness@csl.co.uk> 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: massive quotes?
Next
From: Tom Lane
Date:
Subject: Re: Preliminary notes about hash index concurrency (long)