[ 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
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 knows
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
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 that
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 that an
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
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 (sorry,
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.
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
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-thread-safe
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 functionality, then
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... and you
Olivier PRENANT wrote:
Larry Rosenman wrote:
SNIP
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
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 program that can prove
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 exists, but we still
[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 one can write a program
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_thread
FWIW, I do confirm, on dual XEON with JT enabled
On Wed, 3 Sep 2003, Larry Rosenman wrote:
Date: Wed, 03 Sep 2003 14:53:39 -0500
From: Larry Rosenman [EMAIL PROTECTED]
To: Bruce Momjian [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Unixware Patch (Was: Re
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
Your
--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_thread
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: argument #3 incompatible
--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()
[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]
[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
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
prototype:
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 page:
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
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
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
assure
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 whether
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 question is whether
--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 they don't.
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 simply
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 they don't
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't exist then
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_r()
--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 this
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 area, so
--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:
--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
--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't care. If
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
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 care
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
development
--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 we
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
mutex
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.
That's not our
--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 *_r
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 it is an enormous waste of
--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 the OS isn't thread
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 is that the
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)
whether
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 automatic determination
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 boolean
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-valued
--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
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?
Oh,
--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 an OS
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 *_r but have only
--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. I mean, in
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
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
--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
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
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?
--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
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 threads.
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 the
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 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.
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 how to fix it
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.
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 determination (in
73 matches
Mail list logo
