[ I have retained the original email below so people can remember where
we left this.]
After much agonizing, I have applied a patch to attempt threading in
this order:
use non-*_r function names if they are all thread-safe
(NEED_REENTRANT_FUNCS=no)
use *_r functions if they
On Wed, 10 Sep 2003 02:39 pm, Tom Lane wrote:
> 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.
Not necessarily so - we've managed okay so far (several years) working on
platforms t
Philip Yarra <[EMAIL PROTECTED]> writes:
> On Wed, 10 Sep 2003 02:15 pm, Bruce Momjian wrote:
>
> This would be a pretty short list unless I count wrong! This excludes all
> releases of FreeBSD (and I'm willing to bet other BSDs), Solaris (at least
> the old version I have), OSF, Linux, and who
Philip Yarra <[EMAIL PROTECTED]> 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 functio
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-threa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tripple-yuck. :-)
>
> 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
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tripple-yuck. :-)
>
> 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
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tripple-yuck. :-)
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.
On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
> --- anyway, it is probably threadsafe, but strerror isn't, so we are
> dead anyway. :-)
Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when
everything else is... maybe Strange is OSF's middle name.
> > #ifdef SOME_DEF (sor
Philip Yarra wrote:
> On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> > I see --- looks bad failures below for OSF, Solaris, and FreeBSD
> > below.
>
> Actually, I am not sure the OSF failure is correctly reported... your test app
> had me a little baffled in that case.
Baffler is my m
On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> I see --- looks bad failures below for OSF, Solaris, and FreeBSD
> below.
Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.
> We would have to get some thread mutex, make
Philip Yarra wrote:
> On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
>
> Okay, here's results from the machines I have access to... I think what you're
> going to find is th
On Thu, 4 Sep 2003 05:36 am, Bruce Momjian wrote:
> I would like every operating system that supports thread-safety to run
> this program and report back the results.
Okay, here's results from the machines I have access to... I think what you're
going to find is that an awful lot of platforms tha
Can you pass me what's in CVS (anon hasn't updated afaict).
And, what didn't you like about my version?
LER
--On Wednesday, September 03, 2003 18:35:44 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > What does your OS want for the 3rd argument of pthread_create()? I
Kurt Roeckx wrote:
> On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
> >
> > I would like every operating system that supports thread-safety to run
> > this program and report back the results.
>
> On a Linux system with glibc 2.1:
> Your gethostbyname() is _not_ thread-safe
> Your
Larry Rosenman wrote:
> >> > What does your OS want for the 3rd argument of pthread_create()? I
> >> > thought a void pointer would be OK for everyone:
> >> >
> >> > pthread_create(&thread1, NULL, (void *) func_call_1, NULL);
> >>
> >> void *(*start_routine)(void*)
> >>
> >> Here is our man p
Larry Rosenman wrote:
> >From UnixWare:
>
> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
> prototype: pthread_create()
> UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
> prot
[EMAIL PROTECTED] wrote:
> FWIW, I do confirm, on dual XEON with JT enabled
Operating system?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your
[EMAIL PROTECTED] wrote:
> FWIW, I do confirm, on dual XEON with JT enabled
Oh, I now see OS as Unixware:
> I have 2 bi-pro machines here both running unixware
> 7.1.3 I can make tests if you want
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible
with prototype: pthread_create(
Larry Rosenman wrote:
>
>
> --On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Larry Rosenman wrote:
> >> > From UnixWare:
> >>
> >> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> >> UX:acomp: WARNING: "test_thread.c", line 60: ar
--On Wednesday, September 03, 2003 17:09:49 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Larry Rosenman wrote:
>> > From UnixWare:
>>
>> $ cc -O -Kpthread test_thread.c -o test
On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote:
>
> I would like every operating system that supports thread-safety to run
> this program and report back the results.
On a Linux system with glibc 2.1:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Yo
e: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled
> ...)
>
> >From UnixWare:
>
> $ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
> UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
> prototype: pthread_c
From UnixWare:
$ cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
UX:acomp: WARNING: "test_thread.c", line 60: argument #3 incompatible with
prototype: pthread_create()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
prototype: pthread_create()
$ ./test_threa
[EMAIL PROTECTED] wrote:
> > Olivier PRENANT wrote:
> > > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > > >> asked the threads guys, and he said that the libc stuff is
> > > >> thread-safe so they don't have to have 2 different versions in libc.
> > > >
> > > If any o
--On Wednesday, September 03, 2003 14:00:55 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > Woh, I thought we just agreed that getpwuid_r() isn't required for
>> > thread-safety on your platform.
>> it's CLEANER to use it.
>>
>> Our API Signature is the _r version, why
MAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled
> ...)
>
> Olivier PRENANT wrote:
> > >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> > >> asked the threads guys, and he said that
Larry Rosenman wrote:
> >> > Woh, I thought we just agreed that getpwuid_r() isn't required for
> >> > thread-safety on your platform.
> >> it's CLEANER to use it.
> >>
> >> Our API Signature is the _r version, why not use it when it's available?
> >
> > My new patch will optionally use it if it ex
Olivier PRENANT wrote:
> >> It's ok to assume thread-safety, as the SCO developer (Kean Johnston)
> >> asked the threads guys, and he said that the libc stuff is
> >> thread-safe so they don't have to have 2 different versions in libc.
> >>
> >> LER
> >>
> >>
> >>
> >
> If any one can write a pro
Olivier PRENANT wrote:
Larry Rosenman wrote:
I am inclined to think yes. It would prevent uglification of the code
by not having to special-case Unixware.
However, I was able to read the libc sources to confirm thread-safety.
Because you can not see the source, would you try a threaded progra
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
>> Lee Kindness writes:
>>
>> > You don't..
--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> >> Bruce Momjian writes:
>> >> > Right. We can't assume because a *_r function is missing that
>> >> > the normal function is thread-safe.
>> >
>> >> That's not our concern - if
Larry Rosenman wrote:
> >> >> Bruce Momjian writes:
> >> >> > Right. We can't assume because a *_r function is missing that the
> >> >> > normal function is thread-safe.
> >> >
> >> >> That's not our concern - if the OS isn't thread safe we can't do
> >> >> anything about it, and to worry about
--On Tuesday, September 02, 2003 18:12:48 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
> Lee Kindness writes:
>
>> Bruce Momjian writes:
>> > Right. We can't assume because a
Larry Rosenman wrote:
>
>
> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
> <[EMAIL PROTECTED]> wrote:
>
> > Lee Kindness writes:
> >
> >> Bruce Momjian writes:
> >> > Right. We can't assume because a *_r function is missing that the
> >> > normal function is thread-safe.
Lee Kindness wrote:
> Bruce Momjian writes:
> > Lee Kindness wrote:
> > > No, it's not. Using the _r functions on such systems is BETTER because
> > > the API is clean and the function can be implmented in a reentrant and
> > > thread-safe fashion wuithout the need for thread local storage or
>
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Lee Kindness writes:
Bruce Momjian writes:
> Right. We can't assume because a *_r function is missing that the
> normal function is thread-safe.
That's not our concern - if the OS isn't thread safe
Lee Kindness writes:
> Bruce Momjian writes:
> > Right. We can't assume because a *_r function is missing that the
> > normal function is thread-safe.
> That's not our concern - if the OS isn't thread safe we can't do
> anything about it, and to worry about it is an enormous waste of
> develop
Bruce Momjian writes:
> Lee Kindness wrote:
> > No, it's not. Using the _r functions on such systems is BETTER because
> > the API is clean and the function can be implmented in a reentrant and
> > thread-safe fashion wuithout the need for thread local storage or
> > mutex locking.
> I don't
Bruce Momjian writes:
> Right. We can't assume because a *_r function is missing that the
> normal function is thread-safe.
I recon i'll get blue in the face before long, and one of you guys
will fly over to Scotland to give me a good kicking!... But'll say it
again anyway...
That's not our co
--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
>> Lee Kindness writes:
>>
>> > You don't... and you simply shouldn
Larry Rosenman wrote:
>
>
> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> > Peter Eisentraut wrote:
> >> Lee Kindness writes:
> >>
> >> > You don't... and you simply shouldn't care. If there is a_r version
> >> > available then we should use it -
--On Tuesday, September 02, 2003 11:32:08 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
> Where does it say that you have to use getpwuid_r() to be thread safe?
> I don't see any mention in the docs. It does say about getpwuid:
>
> For getpwent, getpwuid, getpwnam,
Larry Rosenman wrote:
> > Where does it say that you have to use getpwuid_r() to be thread safe?
> > I don't see any mention in the docs. It does say about getpwuid:
> >
> > For getpwent, getpwuid, getpwnam, setpwent, endpwent, and
> > fgetpwent, all information is contained in a static
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Peter Eisentraut wrote:
Lee Kindness writes:
> You don't... and you simply shouldn't care. If there is a_r version
> available then we should use it - even if the plain version is "safe".
The problem with
Peter Eisentraut wrote:
> Lee Kindness writes:
>
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
>
> The problem with this is that the automatic determination (in configure)
> whether there is a xxx
Lee Kindness wrote:
> Tom Lane writes:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > > APIs. They can never be made thread-safe. The *_r versions of these functions
> > > are standardized and required. If they don
--On Tuesday, September 02, 2003 00:04:35 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
>> > Oh, interesting. So you are saying that if the OS supports threads,
>> > then we use the *_r if they have them, and assume the non *_r
>> > functions are already thread-safe if t
Larry Rosenman wrote:
> >> > Oh, interesting. So you are saying that if the OS supports threads,
> >> > then we use the *_r if they have them, and assume the non *_r functions
> >> > are already thread-safe if they don't. Interesting.
> >> >
> >> > That seems to be what we have on Unixware, and o
Lee Kindness writes:
> Tom Lane writes:
> > Greg Stark <[EMAIL PROTECTED]> writes:
> > > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > > APIs. They can never be made thread-safe. The *_r versions of these functions
> > > are standardized and required. If th
Marc G. Fournier wrote:
>
>
> On Mon, 1 Sep 2003, Peter Eisentraut wrote:
>
> > Greg Stark writes:
> >
> > > Um. I don't think that's true. I mean, in theory it's true, but in practice
> > > why would an OS have some *_r but have only non-thread-safe versions of
> > > others?
> >
> > The questio
Tom Lane writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > APIs. They can never be made thread-safe. The *_r versions of these functions
> > are standardized and required. If they don't exist then the platform sim
On Mon, 1 Sep 2003, Peter Eisentraut wrote:
> Greg Stark writes:
>
> > Um. I don't think that's true. I mean, in theory it's true, but in practice
> > why would an OS have some *_r but have only non-thread-safe versions of
> > others?
>
> The question is whether configure can reliably identify w
"Peter Eisentraut" <[EMAIL PROTECTED]> wrote:
> Reentrancy is (usually) a property of the interface (hence *_r functions
> with differing interfaces), thread-safety is a feature of the
> implementation;
May I not agree with this definition ?
Reentrancy is a property of the implemention that
assu
Tom Lane writes:
> This statement is simply false. A platform can build thread-safe
> versions of those "unsafe" APIs if it makes the return values point
> to thread-local storage. Some BSDs do it that way. Accordingly, any
> simplistic "we must have _r to be thread-safe" approach is incorrect.
Greg Stark writes:
> Um. I don't think that's true. I mean, in theory it's true, but in practice
> why would an OS have some *_r but have only non-thread-safe versions of
> others?
The question is whether configure can reliably identify whether various
*_r functions exist. I think it can't. For
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> > APIs. They can never be made thread-safe. The *_r versions of these functions
> > are standardized and required. If they don't exist then
Greg Stark <[EMAIL PROTECTED]> writes:
> On the other hand, things like, getpwnam, strtok, etc have non-thread-safe
> APIs. They can never be made thread-safe. The *_r versions of these functions
> are standardized and required. If they don't exist then the platform simply
> does not support thread
--On Monday, September 01, 2003 22:02:00 +0100 Lee Kindness
<[EMAIL PROTECTED]> wrote:
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
which is my point.
L.
--
Larry Rosenman
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
L.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
htt
"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
--On Monday, September 01, 2003 16:01:16 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
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 threa
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
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
--On Monday, September 01, 2003 14:24:14 -0300 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Mon, 1 Sep 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
>
>
> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> Um. I don't think that's true
On Mon, 1 Sep 2003, Bruce Momjian wrote:
> Larry Rosenman wrote:
> >
> >
> > --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> > <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >> Um. I don't think that's true. I mean, in theory it's true, but in
> > >> practice why would an OS have some *
--On Monday, September 01, 2003 13:11:25 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>
>> Um. I don't think that's true. I mean, in theory it's true, but in
>> practice why would a
Larry Rosenman wrote:
>
>
> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
> <[EMAIL PROTECTED]> wrote:
>
> >
> >> Um. I don't think that's true. I mean, in theory it's true, but in
> >> practice why would an OS have some *_r but have only non-thread-safe
> >> versions of others?
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Um. I don't think that's true. I mean, in theory it's true, but in
practice why would an OS have some *_r but have only non-thread-safe
versions of others?
Oh, interesting. So you are saying that if the OS
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > We could go down that road. The only other OS that needs *_r functions
> > is Linux, and it uses all *_r functions. How do we configure to throw
> > an error in that OS if we don't fined all of them? Maybe we need a
> > three-v
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We could go down that road. The only other OS that needs *_r functions
> is Linux, and it uses all *_r functions. How do we configure to throw
> an error in that OS if we don't fined all of them? Maybe we need a
> three-valued variable instead of bool
Greg Stark wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>
> > Lee Kindness writes:
> >
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> >
> > The problem with this is that the automat
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Lee Kindness writes:
>
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
>
> The problem with this is that the automatic determination (in configure)
>
Kurt Roeckx wrote:
> On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> > Lee Kindness writes:
> >
> > > You don't... and you simply shouldn't care. If there is a_r version
> > > available then we should use it - even if the plain version is "safe".
> >
> > The problem with this
On Sun, Aug 31, 2003 at 12:04:58PM +0200, Peter Eisentraut wrote:
> Lee Kindness writes:
>
> > You don't... and you simply shouldn't care. If there is a_r version
> > available then we should use it - even if the plain version is "safe".
>
> The problem with this is that the automatic determinati
Lee Kindness writes:
> You don't... and you simply shouldn't care. If there is a_r version
> available then we should use it - even if the plain version is "safe".
The problem with this is that the automatic determination (in configure)
whether there is a xxx_r() version is, in general, fragile.
Bruce Momjian writes:
> Marc G. Fournier wrote:
> > On Sat, 30 Aug 2003, Bruce Momjian wrote:
> >
> > > Yes, and that is the complex part because _some_ non-*_r functions are
> > > thread-safe, and some are not. I have to determine if we have other
> > > such platforms before I figure out h
78 matches
Mail list logo
