Beta2 Tag'd and Bundled ...
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
--On Wednesday, August 27, 2003 00:21:23 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
Everything looks like it built clean ... will do a quick, more general
announce tomorrow, but if someone can confirm that things are good, that
would be great ...
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
regards, tom lane
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
I was under the impression he was working on it.
We are shipping a broken template/unixware due to bad spaces....
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.
Could someone tell the rest of the world ahead of time when release steps
are going to happen?
--
Peter Eisentraut peter_e@gmx.net
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
<peter_e@gmx.net> wrote:
Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.Could someone tell the rest of the world ahead of time when release steps
are going to happen?
AND make sure key people are *NOT UNAVAILABLE* for issues?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
<peter_e@gmx.net> wrote:Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.Could someone tell the rest of the world ahead of time when release steps
are going to happen?AND make sure key people are *NOT UNAVAILABLE* for issues?
Larry, you keep going in this direction and I will think about pulling
thread support for Unixware, and the rest of the group might cheer! (SCO
== Unixware) In fact, my just saying someone else has to handle the
Unixware threading issues might kill it right there.
For the record, per platform threading will probably be in flux even
after the final release as we adjust thing for various threading
libraries/flags.
OK, back to the 1k emails that arrived in the last two days.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:Larry Rosenman <ler@lerctr.org> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.I was under the impression he was working on it.
We are shipping a broken template/unixware due to bad spaces....
What bad spaces? Have you looked at current CVS that went into 7.4?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Friday, August 29, 2003 22:58:50 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
<peter_e@gmx.net> wrote:Tom Lane writes:
Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.Could someone tell the rest of the world ahead of time when release
steps are going to happen?AND make sure key people are *NOT UNAVAILABLE* for issues?
Larry, you keep going in this direction and I will think about pulling
thread support for Unixware, and the rest of the group might cheer! (SCO
== Unixware) In fact, my just saying someone else has to handle the
Unixware threading issues might kill it right there.For the record, per platform threading will probably be in flux even
after the final release as we adjust thing for various threading
libraries/flags.OK, back to the 1k emails that arrived in the last two days.
Don't start on the SCO issue. I submitted patches last weekend to fix the
UnixWare (and possibly other) issues.
You said you were working on them, then I see the note that BETA2 was tagged
with INVALID shell code in src/templates/unixware, and
the per-platform threading stuff BROKEN on UnixWare.
When I left for Las Vegas on 8/16, it was **WORKING**. You committed a
change
that BROKE it again.
Yes, I'm pissed.
UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
Does the PG core not care anymore about **QUALITY**?
I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are used
to
hurt PostgreSQL's quality.
I'm NOT very pleased.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
<tgl@sss.pgh.pa.us> wrote:Larry Rosenman <ler@lerctr.org> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.I was under the impression he was working on it.
We are shipping a broken template/unixware due to bad spaces....
What bad spaces? Have you looked at current CVS that went into 7.4?
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$
note the last line before the prompt.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Does the PG core not care anymore about **QUALITY**?
Ummm, I believe that is why we are still in Beta, and not at a Release
Candidate stage ... cause there are still bugs, with Unixware obviously
being one of them ...
--On Saturday, August 30, 2003 00:09:51 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
Does the PG core not care anymore about **QUALITY**?
Ummm, I believe that is why we are still in Beta, and not at a Release
Candidate stage ... cause there are still bugs, with Unixware obviously
being one of them ...
So be it, but I was under the impression that the fix would be committed
shortly after
I posted it on LAST SATURDAY, but apparently Bruce was out of town, and the
Beta2 TAG
was laid, WITHOUT PUBLIC NOTICE about the TAG coming.
Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
about these facts.
I want to see PostgreSQL succeed and take over the Open Source DataBase
world, and
want to help, but y'all are making it HARD.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
Don't start on the SCO issue. I submitted patches last weekend to fix the
UnixWare (and possibly other) issues.You said you were working on them, then I see the note that BETA2 was tagged
with INVALID shell code in src/templates/unixware, and
the per-platform threading stuff BROKEN on UnixWare.When I left for Las Vegas on 8/16, it was **WORKING**. You committed a
change
that BROKE it again.Yes, I'm pissed.
UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
Does the PG core not care anymore about **QUALITY**?
I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are used
to
hurt PostgreSQL's quality.I'm NOT very pleased.
SCO's threading support in a beta release is about number 2000 on my
list of priorities right now. It will work in final --- that's all I
can promise. If that isn't good enough, find someone else who wants to
do the work for you.
I am avoiding fixing the SCO port because it would ugilify the other
ports --- we need to discuss that, not ram in a fix just to get it
working on one platform --- that is quality.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Friday, August 29, 2003 23:17:50 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
Don't start on the SCO issue. I submitted patches last weekend to fix
the UnixWare (and possibly other) issues.You said you were working on them, then I see the note that BETA2 was
tagged with INVALID shell code in src/templates/unixware, and
the per-platform threading stuff BROKEN on UnixWare.When I left for Las Vegas on 8/16, it was **WORKING**. You committed a
change
that BROKE it again.Yes, I'm pissed.
UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
Does the PG core not care anymore about **QUALITY**?
I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are
used to
hurt PostgreSQL's quality.I'm NOT very pleased.
SCO's threading support in a beta release is about number 2000 on my
list of priorities right now. It will work in final --- that's all I
can promise. If that isn't good enough, find someone else who wants to
do the work for you.I am avoiding fixing the SCO port because it would ugilify the other
ports --- we need to discuss that, not ram in a fix just to get it
working on one platform --- that is quality.
where is the discussion happening?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
So be it, but I was under the impression that the fix would be committed
shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
coming.
Beta2 TAG was laid so that we could wrap up all fixes to date, of which
yours for unixware hadn't been included yet ... it had been 3 weeks since
Beta1, there were alot of changes, and if ppl are testing based on the tar
ball and not straight CVS, chances are most bugs reported had already been
fixed ...
Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
about these facts.
This was uncalled for, but so were your comments over one patch ...
I want to see PostgreSQL succeed and take over the Open Source DataBase
world, and want to help, but y'all are making it HARD.
Because one patch wasn't committed before we tar'd up a new beta?
Larry Rosenman wrote:
--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Larry Rosenman wrote:
--On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
<tgl@sss.pgh.pa.us> wrote:Larry Rosenman <ler@lerctr.org> writes:
My UnixWare Thread.c patch/fix has been IGNORED.
I'd like to see a fix before we declare Beta2.Beta2 is a done deal. When Bruce gets back from the seashore I expect
he'll take a look at the issues you raised, but we're not holding off
beta2 another week for that to happen.I was under the impression he was working on it.
We are shipping a broken template/unixware due to bad spaces....
What bad spaces? Have you looked at current CVS that went into 7.4?
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Oh, sorry. Fixed now. I am always thinking that is a makefile when it
isn't.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
Larry Rosenman wrote:
UnixWare==SCO, but the Court fight has **NOTHING** to do with this issue.
Does the PG core not care anymore about **QUALITY**?
I'm NOT going to stand idly by as the SCO/IBM/RED HAT Legal issues are
used to
hurt PostgreSQL's quality.I'm NOT very pleased.
SCO's threading support in a beta release is about number 2000 on my
list of priorities right now. It will work in final --- that's all I
can promise. If that isn't good enough, find someone else who wants to
do the work for you.I am avoiding fixing the SCO port because it would ugilify the other
ports --- we need to discuss that, not ram in a fix just to get it
working on one platform --- that is quality.where is the discussion happening?
That's the problem --- I haven't even had time to collect the
information and post it for comment yet.
Quality is getting the right right, not necessary quickly. You fix was
put on hold because it was complex (for other platforms) and other
things had higher priority.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Marc G. Fournier wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
I didn't realize that space was there until he just posted it --- that I
could have fixed easily.
The major holding point is that SCO is going to require we specify each
*_r function required for threading. SCO doesn't have strerror_r, but
needs the others. That is going to be three functions call options to
be defined per platform we support. I need to know the cleanest way of
attacking that, so I don't break more platforms.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Saturday, August 30, 2003 00:21:29 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
he just sent me a note. That post was from AnonCVS right before I posted.
If what's above is what's in cvs now, we're fine, but we still can't
--enable-thread-safety
due to the code in thread.c.
I'll shut up now.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
--On Friday, August 29, 2003 23:25:06 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Marc G. Fournier wrote:
SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made
a dent in it) after being away, looks like he's committed the fix:SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"I didn't realize that space was there until he just posted it --- that I
could have fixed easily.The major holding point is that SCO is going to require we specify each
*_r function required for threading. SCO doesn't have strerror_r, but
needs the others. That is going to be three functions call options to
be defined per platform we support. I need to know the cleanest way of
attacking that, so I don't break more platforms.
Actually, we **ONLY** have getpwuid_r, not gethostbyname_r nor strerror_r
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:21:29 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS = "$THREAD_CFLAGS -D_REENTRANT"
$note the last line before the prompt.
Check current CVS ... now that Bruce has caught up on his email (or made a
dent in it) after being away, looks like he's committed the fix:SUPPORTS_THREADS=yes
NEED_REENTRANT_FUNC_NAMES=yes
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"he just sent me a note. That post was from AnonCVS right before I posted.
If what's above is what's in cvs now, we're fine, but we still can't
--enable-thread-safety
due to the code in thread.c.I'll shut up now.
In the followup, I posted why I am holding off on the fix --- it
uglifies other platforms, so we need discussion.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
So be it, but I was under the impression that the fix would be committed
shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
coming.Beta2 TAG was laid so that we could wrap up all fixes to date, of which
yours for unixware hadn't been included yet ... it had been 3 weeks since
Beta1, there were alot of changes, and if ppl are testing based on the tar
ball and not straight CVS, chances are most bugs reported had already been
fixed ...Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
about these facts.This was uncalled for, but so were your comments over one patch ...
I want to see PostgreSQL succeed and take over the Open Source DataBase
world, and want to help, but y'all are making it HARD.Because one patch wasn't committed before we tar'd up a new beta?
no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
everytime I ask for UnixWare specific changes.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Fri, 29 Aug 2003, Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:So be it, but I was under the impression that the fix would be committed
shortly after I posted it on LAST SATURDAY, but apparently Bruce was out
of town, and the Beta2 TAG was laid, WITHOUT PUBLIC NOTICE about the TAG
coming.Beta2 TAG was laid so that we could wrap up all fixes to date, of which
yours for unixware hadn't been included yet ... it had been 3 weeks since
Beta1, there were alot of changes, and if ppl are testing based on the tar
ball and not straight CVS, chances are most bugs reported had already been
fixed ...Then the SCO/IBM/RED HAT lawsuits are thrown in my face for complaining
about these facts.This was uncalled for, but so were your comments over one patch ...
I want to see PostgreSQL succeed and take over the Open Source DataBase
world, and want to help, but y'all are making it HARD.Because one patch wasn't committed before we tar'd up a new beta?
no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
everytime I ask for UnixWare specific changes.
'K, since flamewars are just sooooo counter-productive to the task at
hand, can we just drop this and move on?
Larry, can you go to archives and let us know which URL contains the patch
that seems to be 'in question'? And post it in a seperate thread, so that
it doesn't get lost in this whole degraded thread?
--On Saturday, August 30, 2003 00:35:10 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
On Fri, 29 Aug 2003, Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:So be it, but I was under the impression that the fix would be
committed shortly after I posted it on LAST SATURDAY, but apparently
Bruce was out of town, and the Beta2 TAG was laid, WITHOUT PUBLIC
NOTICE about the TAG coming.Beta2 TAG was laid so that we could wrap up all fixes to date, of which
yours for unixware hadn't been included yet ... it had been 3 weeks
since Beta1, there were alot of changes, and if ppl are testing based
on the tar ball and not straight CVS, chances are most bugs reported
had already been fixed ...Then the SCO/IBM/RED HAT lawsuits are thrown in my face for
complaining about these facts.This was uncalled for, but so were your comments over one patch ...
I want to see PostgreSQL succeed and take over the Open Source
DataBase world, and want to help, but y'all are making it HARD.Because one patch wasn't committed before we tar'd up a new beta?
no, because the SCO/IBM/RED HAT lawsuits keep getting thrown in my face
everytime I ask for UnixWare specific changes.'K, since flamewars are just sooooo counter-productive to the task at
hand, can we just drop this and move on?Larry, can you go to archives and let us know which URL contains the patch
that seems to be 'in question'? And post it in a seperate thread, so that
it doesn't get lost in this whole degraded thread?
Here is the patch as posted again (the src/template/unixware change will
need minor
mods for today's CVS).
Index: src/port/thread.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.4
diff -u -r1.4 thread.c
--- src/port/thread.c 16 Aug 2003 15:35:51 -0000 1.4
+++ src/port/thread.c 23 Aug 2003 04:29:15 -0000
@@ -68,7 +68,7 @@
pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result)
{
-#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
+#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) ||
defined(HAVE_GETPWUID_R))
/*
* Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
* getpwuid_r(uid, resultbuf, buffer, buflen)
Index: src/template/unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.15
diff -u -r1.15 unixware
--- src/template/unixware 16 Aug 2003 15:35:51 -0000 1.15
+++ src/template/unixware 23 Aug 2003 04:29:15 -0000
@@ -10,5 +10,5 @@
fi SUPPORTS_THREADS=yes
-NEED_REENTRANT_FUNC_NAMES=yes
-THREAD_CFLAGS += -D_REENTRANT
+#NEED_REENTRANT_FUNC_NAMES=yes
+THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Attachments:
unixware.patch.2application/octet-stream; name=unixware.patch.2Download
Index: src/port/thread.c
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.4
diff -u -r1.4 thread.c
--- src/port/thread.c 16 Aug 2003 15:35:51 -0000 1.4
+++ src/port/thread.c 23 Aug 2003 04:29:15 -0000
@@ -68,7 +68,7 @@
pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result)
{
-#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
+#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) || defined(HAVE_GETPWUID_R))
/*
* Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
* getpwuid_r(uid, resultbuf, buffer, buflen)
Index: src/template/unixware
===================================================================
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.15
diff -u -r1.15 unixware
--- src/template/unixware 16 Aug 2003 15:35:51 -0000 1.15
+++ src/template/unixware 23 Aug 2003 04:29:15 -0000
@@ -10,5 +10,5 @@
fi
SUPPORTS_THREADS=yes
-NEED_REENTRANT_FUNC_NAMES=yes
-THREAD_CFLAGS += -D_REENTRANT
+#NEED_REENTRANT_FUNC_NAMES=yes
+THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"
On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v retrieving revision 1.4 diff -u -r1.4 thread.c --- src/port/thread.c 16 Aug 2003 15:35:51 -0000 1.4 +++ src/port/thread.c 23 Aug 2003 04:29:15 -0000 @@ -68,7 +68,7 @@ pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer, size_t buflen, struct passwd **result) { -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES) +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) || defined(HAVE_GETPWUID_R)) /* * Early POSIX draft of getpwuid_r() returns 'struct passwd *'. * getpwuid_r(uid, resultbuf, buffer, buflen) Index: src/template/unixware =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.15 diff -u -r1.15 unixware --- src/template/unixware 16 Aug 2003 15:35:51 -0000 1.15 +++ src/template/unixware 23 Aug 2003 04:29:15 -0000 @@ -10,5 +10,5 @@ fiSUPPORTS_THREADS=yes -NEED_REENTRANT_FUNC_NAMES=yes -THREAD_CFLAGS += -D_REENTRANT +#NEED_REENTRANT_FUNC_NAMES=yes +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"
'K, my first question on this is shouldn't GETPWUID_R be checked for in
configure, and not hard coded?
My second one is what exactly does this fix/accomplish? It looks to me
like the result is the same, but I might be missing something obvious?
--On Saturday, August 30, 2003 00:57:45 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v retrieving revision 1.4 diff -u -r1.4 thread.c --- src/port/thread.c 16 Aug 2003 15:35:51 -0000 1.4 +++ src/port/thread.c 23 Aug 2003 04:29:15 -0000 @@ -68,7 +68,7 @@ pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer, size_t buflen, struct passwd **result) { -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES) +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) || defined(HAVE_GETPWUID_R)) /* * Early POSIX draft of getpwuid_r() returns 'struct passwd *'. * getpwuid_r(uid, resultbuf, buffer, buflen) Index: src/template/unixware =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.15 diff -u -r1.15 unixware --- src/template/unixware 16 Aug 2003 15:35:51 -0000 1.15 +++ src/template/unixware 23 Aug 2003 04:29:15 -0000 @@ -10,5 +10,5 @@ fiSUPPORTS_THREADS=yes -NEED_REENTRANT_FUNC_NAMES=yes -THREAD_CFLAGS += -D_REENTRANT +#NEED_REENTRANT_FUNC_NAMES=yes +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"'K, my first question on this is shouldn't GETPWUID_R be checked for in
configure, and not hard coded?
It's not checked for currently in configure, and doesn't get set. I'm not
an autoconf
maven.
My second one is what exactly does this fix/accomplish? It looks to me
like the result is the same, but I might be missing something obvious?
No, with the change to NEEDS_REENTRANT_FUNC_NAMES, without the ||
defined(HAVE_GETPWUID_R)
magic, we use getpwuid, and not getpwuid_r, which would break in a threaded
app.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Fri, 29 Aug 2003, Larry Rosenman wrote:
--On Saturday, August 30, 2003 00:57:45 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:On Fri, 29 Aug 2003, Larry Rosenman wrote:
Index: src/port/thread.c =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/port/thread.c,v retrieving revision 1.4 diff -u -r1.4 thread.c --- src/port/thread.c 16 Aug 2003 15:35:51 -0000 1.4 +++ src/port/thread.c 23 Aug 2003 04:29:15 -0000 @@ -68,7 +68,7 @@ pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer, size_t buflen, struct passwd **result) { -#if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES) +#if defined(USE_THREADS) && (defined(NEED_REENTRANT_FUNC_NAMES) || defined(HAVE_GETPWUID_R)) /* * Early POSIX draft of getpwuid_r() returns 'struct passwd *'. * getpwuid_r(uid, resultbuf, buffer, buflen) Index: src/template/unixware =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v retrieving revision 1.15 diff -u -r1.15 unixware --- src/template/unixware 16 Aug 2003 15:35:51 -0000 1.15 +++ src/template/unixware 23 Aug 2003 04:29:15 -0000 @@ -10,5 +10,5 @@ fiSUPPORTS_THREADS=yes -NEED_REENTRANT_FUNC_NAMES=yes -THREAD_CFLAGS += -D_REENTRANT +#NEED_REENTRANT_FUNC_NAMES=yes +THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT -DHAVE_GETPWUID_R"'K, my first question on this is shouldn't GETPWUID_R be checked for in
configure, and not hard coded?It's not checked for currently in configure, and doesn't get set. I'm not
an autoconf
maven.My second one is what exactly does this fix/accomplish? It looks to me
like the result is the same, but I might be missing something obvious?No, with the change to NEEDS_REENTRANT_FUNC_NAMES, without the ||
defined(HAVE_GETPWUID_R) magic, we use getpwuid, and not getpwuid_r,
which would break in a threaded app.
'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the right side of
the && will always resolve to TRUE, before or after the patch ... no?
--On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the right side of
the && will always resolve to TRUE, before or after the patch ... no?
I want to conditionalize ONLY getpwuid_r, and not strerror_r and
gethostbyname_r.
So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
template, and need a configure check to set HAVE_GETPWUID_R, so we will
use getpwuid_r in the ENABLE_THREADS case.
UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and the
libc versions are reentrant in libc, for those 2. We need to use
getpwuid_r for
threaded apps.
Does this clarify things?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first place?
The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the right side of
the && will always resolve to TRUE, before or after the patch ... no?I want to conditionalize ONLY getpwuid_r, and not strerror_r and
gethostbyname_r.So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
template, and need a configure check to set HAVE_GETPWUID_R, so we will
use getpwuid_r in the ENABLE_THREADS case.UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and the
libc versions are reentrant in libc, for those 2. We need to use
getpwuid_r for
threaded apps.Does this clarify things?
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 in the cleanest way.
In most platforms that are like this, I think, they have all the *_r
functions even if all of them are not required.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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 in the cleanest way.
Long shot ... is there some way of writing a configure test for this?
Right now, it sounds like we're going to be hitting alot of trial-n-error
if there isn't ...
--On Saturday, August 30, 2003 00:17:41 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:'K, but why the change to NEEDS_REENTRANT_FUNC_NAMES in the first
place?The thing that has me most confused here is that the end result is the
same with or without the patch, from what I can tell ... the right
side of the && will always resolve to TRUE, before or after the patch
... no?I want to conditionalize ONLY getpwuid_r, and not strerror_r and
gethostbyname_r.So, I changed the NEED_REENTRANT_FUNC_NAMES to no, or undefined in the
template, and need a configure check to set HAVE_GETPWUID_R, so we will
use getpwuid_r in the ENABLE_THREADS case.UnixWare does NOT have strerror_r nor does it have gethostbyname_r, and
the libc versions are reentrant in libc, for those 2. We need to use
getpwuid_r for
threaded apps.Does this clarify things?
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 in the cleanest way.In most platforms that are like this, I think, they have all the *_r
functions even if all of them are not required.
well, this is not true on FreeBSD.
it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).
It does have getpwuid_r and strerror_r.
FWIW.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 in the cleanest way.Long shot ... is there some way of writing a configure test for this?
Right now, it sounds like we're going to be hitting alot of trial-n-error
if there isn't ...
How would we test if a function is thread-safe? I can't think of a
reliable way, and hence my warning that this adjusting could take a
while.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry Rosenman 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 in the cleanest way.In most platforms that are like this, I think, they have all the *_r
functions even if all of them are not required.well, this is not true on FreeBSD.
it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).
It does have getpwuid_r and strerror_r.
Yes, but it doesn't require those *_r functions. It uses a separate
library. It has them around only for compatibility, or so I am told.
Seems netbsd also needs them, but it seems it has them all.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Saturday, August 30, 2003 00:51:01 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman 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 in the cleanest way.In most platforms that are like this, I think, they have all the *_r
functions even if all of them are not required.well, this is not true on FreeBSD.
it does NOT have gethostbyname_r (on 5.1-CURRENT as of last nite).
It does have getpwuid_r and strerror_r.
Yes, but it doesn't require those *_r functions. It uses a separate
library. It has them around only for compatibility, or so I am told.Seems netbsd also needs them, but it seems it has them all.
The only two platforms I have are FreeBSD and UnixWare.
So, I can't help more here.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 in the cleanest way.Long shot ... is there some way of writing a configure test for this?
Right now, it sounds like we're going to be hitting alot of trial-n-error
if there isn't ...How would we test if a function is thread-safe? I can't think of a
reliable way, and hence my warning that this adjusting could take a
while.
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".
Just think of this as is it were a normal "port" issue. If an OS
doesn't have zxczxc_r() then we need to write a zxczxc_r() wrapper
function which calls zxczxc() and has the same signature as
zxczxc_r().
L.
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. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.
I don't see any other solution than keeping a database of NEED_XXX_R for
each platform and then requiring these functions to show up before we
declare a library to be thread-safe. So far we're only dealing with three
functions, to it should be doable.
--
Peter Eisentraut peter_e@gmx.net
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 configure)
whether there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.
I think you missed a part of his email. He says that if xxx_r()
isn't available, we should provide an xxx_r() ourself.
Kurt
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 automatic determination (in configure)
whether there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.I think you missed a part of his email. He says that if xxx_r()
isn't available, we should provide an xxx_r() ourself.
The big problem there is that many platforms don't have *_r functions,
and their normal library functions are thread-safe, even if they return
pointers to static memory area. See the comment at the top of
src/port/thread.c.
Looking at our current setup in src/template:
bsdi:NEED_REENTRANT_FUNC_NAMES=no
freebsd:NEED_REENTRANT_FUNC_NAMES=no
linux:NEED_REENTRANT_FUNC_NAMES=yes
netbsd:NEED_REENTRANT_FUNC_NAMES=no
osf:NEED_REENTRANT_FUNC_NAMES=no
unixware:NEED_REENTRANT_FUNC_NAMES=yes
So, the only OS's that want any *_r functions are linux and unixware.
Linux wants all of them, and Unixware wants (and has) only one of them.
I am leaning to doing an OS define test in thread.c to prevent usage of
the *_r functions they don't have, and mentioning it as a comment in the
template file (until I find another OS that needs this customization).
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Peter Eisentraut <peter_e@gmx.net> 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 there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.
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 only OSes like that would be ones that were in the process of developing
thread-safe libraries and hadn't finished yet. Perhaps early versions of
Solaris or CVS snapshots of BSD? I don't know of any actual releases that
anyone would want to be running today.
Postgres doesn't need to work around problems like that. At worst it should
have a blacklist of OS versions that it knows not to even bother building a
threadsafe libpq for.
--
greg
Greg Stark wrote:
Peter Eisentraut <peter_e@gmx.net> 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 there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.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 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 on BSD/OS I have some *_r
functions but not others, but they are all threadsafe, so your plan
works there too.
The only OSes like that would be ones that were in the process of developing
thread-safe libraries and hadn't finished yet. Perhaps early versions of
Solaris or CVS snapshots of BSD? I don't know of any actual releases that
anyone would want to be running today.Postgres doesn't need to work around problems like that. At worst it should
have a blacklist of OS versions that it knows not to even bother building a
threadsafe libpq for.
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 NEED_REENTRANT_FUNC_NAMES. We
could call it just REENTRANT_FUNC_NAMES and it could have values
'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE
values.
That sounds like a clear plan.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian <pgman@candle.pha.pa.us> 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 NEED_REENTRANT_FUNC_NAMES. We
could call it just REENTRANT_FUNC_NAMES and it could have values
'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE
values.
Actually I don't think that's true for linux. Linux only has *_r functions
that are required, not unnecessary ones.
Note that there are two different types of _r functions being discussed here.
getpwuid, for example, has a thread-safe API. There's really no reason for a
getpwuid_r to exist on any platform. If it exists then it must simply be a
thread-safe version of the regular function. But if it doesn't the regular
function must be thread-safe if the platform supports threads at all.
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.
My questions are:
Are there OSes that have strtok_r et al. because standards require them but
have no OS threads support at all? In which case the library would be
"thread-safe" but not really usefully so.
Are there OSes that have extraneous *_r functions like getpwuid_r but only for
compatibility and they're deprecated?
--
greg
Greg Stark wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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 NEED_REENTRANT_FUNC_NAMES. We
could call it just REENTRANT_FUNC_NAMES and it could have values
'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE
values.Actually I don't think that's true for linux. Linux only has *_r functions
that are required, not unnecessary ones.Note that there are two different types of _r functions being discussed here.
getpwuid, for example, has a thread-safe API. There's really no reason for a
getpwuid_r to exist on any platform. If it exists then it must simply be a
thread-safe version of the regular function. But if it doesn't the regular
function must be thread-safe if the platform supports threads at all.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.My questions are:
Are there OSes that have strtok_r et al. because standards require them but
have no OS threads support at all? In which case the library would be
"thread-safe" but not really usefully so.Are there OSes that have extraneous *_r functions like getpwuid_r but only for
compatibility and they're deprecated?
Have you read the comment at the top of port/thread.c? There is a way
to make those thread-safe using per-thread global variables, I think.
Anyway, require doesn't mean we need all the *_r functions that exist,
just that we need the *_r functions that appear in thread.c.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 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 on BSD/OS I have some *_r
functions but not others, but they are all threadsafe, so your plan
works there too.
UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe
unless
told otherwise.
[snip]
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 NEED_REENTRANT_FUNC_NAMES. We
could call it just REENTRANT_FUNC_NAMES and it could have values
'require', 'prefer', 'disable'. This mimicks libpq's new PGSSLMODE
values.That sounds like a clear plan.
I have no preference. I would just like to see a thread-safe libpq.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 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 on BSD/OS I have some *_r
functions but not others, but they are all threadsafe, so your plan
works there too.UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe
unless
told otherwise.
What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Monday, September 01, 2003 13:11:25 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 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 on BSD/OS I have some
*_r functions but not others, but they are all threadsafe, so your plan
works there too.UnixWare's Kernel is threaded, and I assume anything in libc is
threadsafe unless
told otherwise.What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.
right, getpwuid is not threadsafe, so we use the provided getpwuid_r.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
On Mon, 1 Sep 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 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 on BSD/OS I have some *_r
functions but not others, but they are all threadsafe, so your plan
works there too.UnixWare's Kernel is threaded, and I assume anything in libc is threadsafe
unless
told otherwise.What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.
Note that Larry said "unless told otherwise", so I'm guessing that there
is somewhere in Unixware taht states that standard getpwuid isn't thread
safe? :)
--On Monday, September 01, 2003 14:24:14 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:
On Mon, 1 Sep 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
--On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 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 on BSD/OS I have some
*_r functions but not others, but they are all threadsafe, so your
plan works there too.UnixWare's Kernel is threaded, and I assume anything in libc is
threadsafe unless
told otherwise.What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.Note that Larry said "unless told otherwise", so I'm guessing that there
is somewhere in Unixware taht states that standard getpwuid isn't thread
safe? :)
http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html
the above is the manual page as used on UnixWare. See the very end.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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.
Together both steps ensure the code calling the _r function is
readable (just one function signature) and that libpq will be
thread-safe if the system C library is thread-safe. So this will catch
all modern UNIX OSs.
We really don't want to go deeper than this - of we do so we're
wasting time on odd-ball systems that aren't thread-safe anyway - so
for them libpq's thread-safety is of no consequence.
L.
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.
regards, tom lane
--On Monday, September 01, 2003 16:01:16 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
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.
then how do we *PROVE* thread-safety on a particular platform?
In my case on UnixWare, we assume all libc is thread-safe except for those
that
are specifically called out.
the getpwuid() function has a _r version, so we can use that. the
gethostbyname and strerror functions do *NOT* have a _r version, but are
assumed thread-safe.
The current (cvs) version can't build a thread-safe libpq, but with my
patch it does build.
LER
regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
"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.
"Larry Rosenman" <ler@lerctr.org> writes:
then how do we *PROVE* thread-safety on a particular platform?
You're not going to be able to prove it anyway!
L.
--On Monday, September 01, 2003 22:02:00 +0100 Lee Kindness
<lkindness@csl.co.uk> wrote:
"Larry Rosenman" <ler@lerctr.org> 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 http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Greg Stark <gsstark@mit.edu> 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.
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.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes:
Greg Stark <gsstark@mit.edu> 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.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.
Except there are standards that describe things like strtok_r and such. If the
OS doesn't have those standard functions at all then it probably doesn't have
a thread-safe strtok.
Moreover I was somewhat disturbed when I read that in port/thread.c. It seems
rather a dramatic non-standard API change for these functions. It must break
programs and libraries that expect these to have global state accessible from
any thread. I suspect if I check back in the BSD mailing lists there were
flamewars over this at the time.
Generally I would prefer to use standards-dictated _r functions than depend on
non-standard thread-local api extensions. Especially since many platforms have
slow thread-local storage implementations.
In any case I think I'm bowing out of this discussion. It seems like a simple
matter has gotten way out of hand and I feel like a troll here. Sorry for
fueling the confusion.
--
greg
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 example, they could be in a
separate library that we don't know about.
--
Peter Eisentraut peter_e@gmx.net
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.
That's the difference between being thread-safe and being reentrant.
Reentrancy is (usually) a property of the interface (hence *_r functions
with differing interfaces), thread-safety is a feature of the
implementation; both are orthogonal properties. The Unix standards sort
of encourage making one dependent on the other, which might be where this
confusion comes from.
--
Peter Eisentraut peter_e@gmx.net
"Peter Eisentraut" <peter_e@gmx.net> 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 that the code can be executed simultaneously
by concurrent program.
Thread safety instead involve concept like critical section
and the ability to force the non execution simultaneously
of part of the code.
I agree anyway that are orthogonal concept.
Regards
Gaetano Mendola
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 various
*_r functions exist. I think it can't. For example, they could be in a
separate library that we don't know about.
'K, but isn't that just a matter of adding an extra test when such
'extra libraries' are identified? I've seen it before, in order
configures, where it tests for the same function in a couple of different
libraries ...
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 configure can reliably identify whether various
*_r functions exist. I think it can't. For example, they could be in a
separate library that we don't know about.'K, but isn't that just a matter of adding an extra test when such
'extra libraries' are identified? I've seen it before, in order
configures, where it tests for the same function in a couple of different
libraries ...
We do have tests for *_r functions now in configure.in, and it does use
any thread-specific library/compiler flags defined in the OS template.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry 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 on BSD/OS I have some
*_r functions but not others, but they are all threadsafe, so your plan
works there too.UnixWare's Kernel is threaded, and I assume anything in libc is
threadsafe unless
told otherwise.What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.right, getpwuid is not threadsafe, so we use the provided getpwuid_r.
Larry, I read the URL you gave me:
http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html
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 it must be
copied if it is to be
but that in itself doesn't mean it isn't thread safe. If you are not
sure, would you write a little thread program to test if it works if two
threads try it at the same time.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 00:04:35 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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. Interesting.That seems to be what we have on Unixware, and on BSD/OS I have some
*_r functions but not others, but they are all threadsafe, so your
plan works there too.UnixWare's Kernel is threaded, and I assume anything in libc is
threadsafe unless
told otherwise.What? You said Unixware needs getpwuid_r. And this has nothing to do
with whether the kernel is threaded.right, getpwuid is not threadsafe, so we use the provided getpwuid_r.
Larry, I read the URL you gave me:
http://www.lerctr.org:8458/en/man/html.3C/getpwent.3C.html
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 it must be
copied if it is to bebut that in itself doesn't mean it isn't thread safe. If you are not
sure, would you write a little thread program to test if it works if two
threads try it at the same time.
I only have a UP box.
Since the _r version uses OUR OWN buffer, it is safer to use the _r version.
Since we do NOT have the _r alternative for strerror and gethostbyname,
that's the
best we can do.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane writes:
Greg Stark <gsstark@mit.edu> 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.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.
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.
L.
Lee Kindness writes:
Tom Lane writes:
Greg Stark <gsstark@mit.edu> 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.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.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.
Sorry Tom, I should have read a bit more carefully! Yeah, I agree with
your point that the lack of _r functions doesn't mean the platform is
non thread-safe!
L.
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() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.I don't see any other solution than keeping a database of NEED_XXX_R for
each platform and then requiring these functions to show up before we
declare a library to be thread-safe. So far we're only dealing with three
functions, to it should be doable.
Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Lee Kindness wrote:
Tom Lane writes:
Greg Stark <gsstark@mit.edu> 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.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.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 about overhead at this point. These functions are rarely
called.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 is that the automatic determination (in configure)
whether there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.I don't see any other solution than keeping a database of NEED_XXX_R for
each platform and then requiring these functions to show up before we
declare a library to be thread-safe. So far we're only dealing with
three functions, to it should be doable.Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.
So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but
does have
getpwuid_r, will y'all declare that UnixWare has thread-safety?
My vote is YES.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 it must be
copied if it is to bebut that in itself doesn't mean it isn't thread safe. If you are not
sure, would you write a little thread program to test if it works if two
threads try it at the same time.I only have a UP box.
Since the _r version uses OUR OWN buffer, it is safer to use
the _r version.Since we do NOT have the _r alternative for strerror and
gethostbyname, that's the best we can do.
Uh, that's not the logic I use. I have some *_r functions on BSD/OS,
but the normal libc functions are thread-safe, so I just use those. I
think I have the *_r functions because the standards require them to
exist, not because they are required for thread-safety, and like
Unixware, I have some of them, but not others (no strerror_r). Because
Unixware is similar in that it has some *_r functions and not others, I
want to know if getpwuid_r() is required.
gethostbyname() also returns data from a static area. Why is that
thread-safe on Unixware and getpwuid() is not? My guess is that both
are thread-safe but some software requires getpwuid_r() so they added
it. Again, on those OS's, it is better to just use the libc versions.
"Safer" isn't an issue. Either it is safe or unsafe. I also don't care
about locking overhead in the libc versions of these functions.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 11:32:08 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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, setpwent, endpwent, and
fgetpwent, all information is contained in a static area, so it
must be copied if it is to bebut that in itself doesn't mean it isn't thread safe. If you are not
sure, would you write a little thread program to test if it works if
two threads try it at the same time.I only have a UP box.
Since the _r version uses OUR OWN buffer, it is safer to use
the _r version.Since we do NOT have the _r alternative for strerror and
gethostbyname, that's the best we can do.Uh, that's not the logic I use. I have some *_r functions on BSD/OS,
but the normal libc functions are thread-safe, so I just use those. I
think I have the *_r functions because the standards require them to
exist, not because they are required for thread-safety, and like
Unixware, I have some of them, but not others (no strerror_r). Because
Unixware is similar in that it has some *_r functions and not others, I
want to know if getpwuid_r() is required.gethostbyname() also returns data from a static area. Why is that
thread-safe on Unixware and getpwuid() is not? My guess is that both
are thread-safe but some software requires getpwuid_r() so they added
it. Again, on those OS's, it is better to just use the libc versions."Safer" isn't an issue. Either it is safe or unsafe. I also don't care
about locking overhead in the libc versions of these functions.
My take is unless otherwise stated, all libc functions are thread-safe on
UnixWare.
the *_r functions are better if available as they require the USER to
allocate/pass
their OWN buffer. We should use those (that's the signature we use in
src/port/thread.c),
but if they don't exist, we should just use the non-*_r version.
If the OS supports threads, this *should* work.
My $0.02.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 is that the automatic determination (in configure)
whether there is a xxx_r() version is, in general, fragile. We cannot
rely on configure saying that xxx_r() doesn't exist, so the plain xxx()
should be good enough. Else, we'd be shipping claimed-to-be-thread-safe
libraries that might trigger bugs that will be hard to track down.I don't see any other solution than keeping a database of NEED_XXX_R for
each platform and then requiring these functions to show up before we
declare a library to be thread-safe. So far we're only dealing with
three functions, to it should be doable.Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but
does have
getpwuid_r, will y'all declare that UnixWare has thread-safety?My vote is YES.
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 program and
see if calls to getpwuid from different threads return different
pointer values?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 is that the automatic determination (in
configure) whether there is a xxx_r() version is, in general,
fragile. We cannot rely on configure saying that xxx_r() doesn't
exist, so the plain xxx() should be good enough. Else, we'd be
shipping claimed-to-be-thread-safe libraries that might trigger bugs
that will be hard to track down.I don't see any other solution than keeping a database of NEED_XXX_R
for each platform and then requiring these functions to show up
before we declare a library to be thread-safe. So far we're only
dealing with three functions, to it should be doable.Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.So, given that UnixWare doesn't have gethostbyname_r and strerror_r, but
does have
getpwuid_r, will y'all declare that UnixWare has thread-safety?My vote is YES.
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 program and
see if calls to getpwuid from different threads return different
pointer values?
It won't prove anything on MY box, as it is a UNIPROCESSOR, so the threads
won't be dispatched at the same time.
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
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 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 time.
Who do you think is interested in a thread-safe libpq on a
non-thread-safe OS?
L.
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 about overhead at this point. These functions are rarely
called.
Nor do I, but there is no requirement or point in using the
traditional interface over the _r one then the traditional one is
known to be thread-safe. It only adds additional complexity.
L.
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 time.
There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe. There are
many uncertainties along that way, and I believe my point was that the
only way we can get a degree of certainty about the result of a particular
build is that we keep a database of exactly what is required for
thread-safety on each platform.
--
Peter Eisentraut peter_e@gmx.net
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<peter_e@gmx.net> 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 can't do
anything about it, and to worry about it is an enormous waste of
development time.There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe. There are
many uncertainties along that way, and I believe my point was that the
only way we can get a degree of certainty about the result of a particular
build is that we keep a database of exactly what is required for
thread-safety on each platform.
Ok, now, is my statement from a SCO Developer good enough to get
thread-safety enabled
on UnixWare with only the getpwuid_r() function?
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 locking.I don't care about overhead at this point. These functions are rarely
called.Nor do I, but there is no requirement or point in using the
traditional interface over the _r one then the traditional one is
known to be thread-safe. It only adds additional complexity.
I am working on a patch that will _prefer_ the *_r functions, but only
fail if not found when the OS is marked as requiring them. At this
point, the only OS so marked is Linux and Unixware (though my patch will
change Unixware to not requiring *_r).
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<peter_e@gmx.net> 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 can't do
anything about it, and to worry about it is an enormous waste of
development time.There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe. There are
many uncertainties along that way, and I believe my point was that the
only way we can get a degree of certainty about the result of a particular
build is that we keep a database of exactly what is required for
thread-safety on each platform.Ok, now, is my statement from a SCO Developer good enough to get
thread-safety enabled
on UnixWare with only the getpwuid_r() function?
Woh, I thought we just agreed that getpwuid_r() isn't required for
thread-safety on your platform.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 18:12:48 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<peter_e@gmx.net> 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 can't do
anything about it, and to worry about it is an enormous waste of
development time.There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe. There
are many uncertainties along that way, and I believe my point was that
the only way we can get a degree of certainty about the result of a
particular build is that we keep a database of exactly what is
required for thread-safety on each platform.Ok, now, is my statement from a SCO Developer good enough to get
thread-safety enabled
on UnixWare with only the getpwuid_r() function?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?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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
development time.There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe. There
are many uncertainties along that way, and I believe my point was that
the only way we can get a degree of certainty about the result of a
particular build is that we keep a database of exactly what is
required for thread-safety on each platform.Ok, now, is my statement from a SCO Developer good enough to get
thread-safety enabled
on UnixWare with only the getpwuid_r() function?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 need to
know if it is required so if we don't find it, we throw an error.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Tuesday, September 02, 2003 18:32:03 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 safe we can't do
anything about it, and to worry about it is an enormous waste of
development time.There is a long way between configure not finding a particular *_r
function and the entire operating system not being thread-safe.
There are many uncertainties along that way, and I believe my point
was that the only way we can get a degree of certainty about the
result of a particular build is that we keep a database of exactly
what is required for thread-safety on each platform.Ok, now, is my statement from a SCO Developer good enough to get
thread-safety enabled
on UnixWare with only the getpwuid_r() function?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 need to
know if it is required so if we don't find it, we throw an error.
On UnixWare, either should be thread-safe, to the best of my knowledge.
HOWEVER,
UnixWare has the getpwuid_r version, and since our API(from thread.c) is
the _r signature,
we should just return getpwuid_r(...,....,..., etc).
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:35:25 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:Larry Rosenman wrote:
--On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 is that the automatic determination (in
configure) whether there is a xxx_r() version is, in general,
fragile. We cannot rely on configure saying that xxx_r() doesn't
exist, so the plain xxx() should be good enough. Else, we'd be
shipping claimed-to-be-thread-safe libraries that might trigger bugs
that will be hard to track down.I don't see any other solution than keeping a database of NEED_XXX_R
for each platform and then requiring these functions to show up
before we declare a library to be thread-safe. So far we're only
dealing with three functions, to it should be doable.Right. We can't assume because a *_r function is missing that the
normal function is thread-safe.So, given that UnixWare doesn't have gethostbyname_r and strerror_r,
but
does have
getpwuid_r, will y'all declare that UnixWare has thread-safety?My vote is YES.
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 program and
see if calls to getpwuid from different threads return different
pointer values?It won't prove anything on MY box, as it is a UNIPROCESSOR, so the
threads won't be dispatched at the same time.
I have 2 bi-pro machines here both running unixware 7.1.3 I can make
tests if you want
Show quoted text
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
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 program
and
see if calls to getpwuid from different threads return different
pointer values?It won't prove anything on MY box, as it is a UNIPROCESSOR, so the
threads won't be dispatched at the same time.I have 2 bi-pro machines here both running unixware 7.1.3 I can make
tests if you wantIt'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 anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So that
we (you?) can move on with the other unixware patches.
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 anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So that
we (you?) can move on with the other unixware patches.
You don't need a SMP machine to test threads. You just need one thread
to do the function call, then another to do the function call and see if
the two pointers are different. They calls don't have to happen at the
same time. Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry 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 need to
know if it is required so if we don't find it, we throw an error.On UnixWare, either should be thread-safe, to the best of my knowledge.
HOWEVER,
UnixWare has the getpwuid_r version, and since our API(from thread.c) is
the _r signature,
we should just return getpwuid_r(...,....,..., etc).
OK, I have marked Unixware as not requiring *_r functions. I decided
against optionally using the *_r functions if they exist because it
requires more tests/defines in configure.in, the standard changed the
arguments for some *_r functions over time (from drafts), and there is
no advantage if the libc versions are thread-safe already.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Ok, I don't know much about threads; would you write a simple program for
us to test?
On Wed, 3 Sep 2003, Bruce Momjian wrote:
Date: Wed, 3 Sep 2003 13:58:53 -0400 (EDT)
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Olivier PRENANT <ohp@pyrenet.fr>
Cc: pgsql-hackers@postgresql.org
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 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 anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So that
we (you?) can move on with the other unixware patches.You don't need a SMP machine to test threads. You just need one thread
to do the function call, then another to do the function call and see if
the two pointers are different. They calls don't have to happen at the
same time. Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
--On Wednesday, September 03, 2003 14:00:55 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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 not use it when it's
available?My new patch will optionally use it if it exists, but we still need to
know if it is required so if we don't find it, we throw an error.On UnixWare, either should be thread-safe, to the best of my knowledge.
HOWEVER,
UnixWare has the getpwuid_r version, and since our API(from thread.c) is
the _r signature,
we should just return getpwuid_r(...,....,..., etc).OK, I have marked Unixware as not requiring *_r functions. I decided
against optionally using the *_r functions if they exist because it
requires more tests/defines in configure.in, the standard changed the
arguments for some *_r functions over time (from drafts), and there is
no advantage if the libc versions are thread-safe already.
Ok, I guess I can live with this, but our API from the rest of libpq to
thread.c is
the getpwuid_r() api.
I would think it would make more sense to use it if it's available.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
ohp@pyrenet.fr 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 that can prove anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So that
we (you?) can move on with the other unixware patches.You don't need a SMP machine to test threads. You just need one thread
to do the function call, then another to do the function call and see if
the two pointers are different. They calls don't have to happen at the
same time. Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.Ok, I don't know much about threads; would you write a simple program for
us to test?
OK, done, and attached. It is also now in CVS as
src/tools/test_thread_funcs.c.
In hindsight, I should have done this long ago. However, it only tests
the thread-safety of functions. It does not completely test your threading
capability.
I would like every operating system that supports thread-safety to run
this program and report back the results.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
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
Your functions are all thread-safe
$
--On Wednesday, September 03, 2003 15:36:53 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
ohp@pyrenet.fr 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 that can prove anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So
that we (you?) can move on with the other unixware patches.You don't need a SMP machine to test threads. You just need one thread
to do the function call, then another to do the function call and see
if the two pointers are different. They calls don't have to happen at
the same time. Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.Ok, I don't know much about threads; would you write a simple program for
us to test?OK, done, and attached. It is also now in CVS as
src/tools/test_thread_funcs.c.In hindsight, I should have done this long ago. However, it only tests
the thread-safety of functions. It does not completely test your
threading capability.I would like every operating system that supports thread-safety to run
this program and report back the results.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
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 <ler@lerctr.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>, ohp@pyrenet.fr
Cc: pgsql-hackers@postgresql.org
Subject: Re: [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_create()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible with
prototype: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$--On Wednesday, September 03, 2003 15:36:53 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:ohp@pyrenet.fr 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 that can prove anything (I can't), I'm
willing to test it here on a bi-pro (bi PIII and bi-XEON with JT
enabled) running uw713.
Maybe it will end the discussion and make a point in either way. So
that we (you?) can move on with the other unixware patches.You don't need a SMP machine to test threads. You just need one thread
to do the function call, then another to do the function call and see
if the two pointers are different. They calls don't have to happen at
the same time. Ideally you could make call in the two threads with
different arguments, then after both calls are completed, test that the
two static areas have the proper _different_ values.Ok, I don't know much about threads; would you write a simple program for
us to test?OK, done, and attached. It is also now in CVS as
src/tools/test_thread_funcs.c.In hindsight, I should have done this long ago. However, it only tests
the thread-safety of functions. It does not completely test your
threading capability.I would like every operating system that supports thread-safety to run
this program and report back the results.
--
Olivier PRENANT Tel: +33-5-61-50-97-00 (Work)
6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax)
31190 AUTERIVE +33-6-07-63-80-64 (GSM)
FRANCE Email: ohp@pyrenet.fr
------------------------------------------------------------------------------
Make your life a dream, make your dream a reality. (St Exupery)
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: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$
Well, that's great news, and so clear too!
I am curious about the compiler warnings.
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);
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073ohp@pyrenet.fr wrote:
FWIW, I do confirm, on dual XEON with JT enabled
Operating system?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073ohp@pyrenet.fr 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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
with prototype: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$Well, that's great news, and so clear too!
I am curious about the compiler warnings.
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:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthread.
html
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
with prototype: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$Well, that's great news, and so clear too!
I am curious about the compiler warnings.
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:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthread.
html
Yes, that's what I have too. What if you have the functions taking
(void *) rather than void. Does that make the warnings disappear?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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 functions are _not_ all thread-safe
From a Linux system with libc5:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
Kurt
--On Wednesday, September 03, 2003 17:09:49 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
--On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> 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()
UX:acomp: WARNING: "test_thread.c", line 61: argument #3 incompatible
with prototype: pthread_create()
$ ./test_thread
Your functions are all thread-safe
$Well, that's great news, and so clear too!
I am curious about the compiler warnings.
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:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthre
ad. htmlYes, that's what I have too. What if you have the functions taking
(void *) rather than void. Does that make the warnings disappear?
$ r cc
cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
$ ./test_thread
Your functions are all thread-safe
$
Attached is my modified version.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Attachments:
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 getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeFrom a Linux system with libc5:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
Thanks.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Larry 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:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pthre
ad. htmlYes, that's what I have too. What if you have the functions taking
(void *) rather than void. Does that make the warnings disappear?$ r cc
cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
$ ./test_thread
Your functions are all thread-safe
$
I have updated the code to tighten the cast:
pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);
The change is in CVS. Does that fix it?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Can 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
<pgman@candle.pha.pa.us> wrote:
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:
http://lerami.lerctr.org:8458/en/man/html.3pthread/pthread_create.3pt
hre ad. htmlYes, that's what I have too. What if you have the functions taking
(void *) rather than void. Does that make the warnings disappear?$ r cc
cc -O -Kpthread test_thread.c -o test_thread -lsocket -lnsl
$ ./test_thread
Your functions are all thread-safe
$I have updated the code to tighten the cast:
pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1,
NULL); pthread_create(&thread2, NULL, (void * (*)(void *))
func_call_2, NULL);The change is in CVS. Does that fix it?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
FreeBSD 4.8/i386:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
Chris
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Kurt Roeckx" <Q@ping.be>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, September 04, 2003 6:07 AM
Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)
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 getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeFrom a Linux system with libc5:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeThanks.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania
19073
Show quoted text
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Christopher Kings-Lynne wrote:
FreeBSD 4.8/i386:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
Interesting. Do you have all the *_r files listed in thread.c? I sure
hope so. I assume you used the template thread compile flags for this
test.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
-On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeInteresting. Do you have all the *_r files listed in thread.c? I sure
hope so. I assume you used the template thread compile flags for this
test.
Both gethostbyname() and getpwuid() have no _r equivalents on
FreeBSD-STABLE, ergo no thread-safe functions of these.
--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
Gravitation can not be held responsible for people falling in love...
Jeroen Ruigrok/asmodai wrote:
-On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeInteresting. Do you have all the *_r files listed in thread.c? I sure
hope so. I assume you used the template thread compile flags for this
test.Both gethostbyname() and getpwuid() have no _r equivalents on
FreeBSD-STABLE, ergo no thread-safe functions of these.
So you don't have all the *_r functions, and your non-*_r functions
aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Monday, September 08, 2003 12:50:18 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Jeroen Ruigrok/asmodai wrote:
-On [20030908 06:32], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeInteresting. Do you have all the *_r files listed in thread.c? I sure
hope so. I assume you used the template thread compile flags for this
test.Both gethostbyname() and getpwuid() have no _r equivalents on
FreeBSD-STABLE, ergo no thread-safe functions of these.So you don't have all the *_r functions, and your non-*_r functions
aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
Same is true on 5.1-CURRENT:
$ uname -a
FreeBSD lerlaptop-red.iadfw.net 5.1-CURRENT FreeBSD 5.1-CURRENT #51: Mon
Sep 8 05:52:15 CDT 2003
ler@lerlaptop.lerctr.org:/usr/obj/usr/src/sys/LERLAPTOP i386
$ ls -l test_t*
-rwxr-xr-x 1 ler ler 6689 Sep 3 16:40 test_thread
-rw------- 1 ler ler 3611 Sep 3 16:22 test_thread.c
-rw------- 1 ler ler 3638 Sep 3 19:01 test_thread2.c
$ cc -O -o test_thread2 test_thread2.c -lc_r
$ ./test_thread2
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
$ man -k gethostbyname_r
gethostbyname_r: nothing appropriate
$ man -k getpwuid
getpwent(3), getpwent_r(3), getpwnam(3), getpwnam_r(3), getpwuid(3),
getpwuid_r(
3), setpassent(3), setpwent(3), endpwent(3) - password database operations
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
-On [20030908 18:52], Bruce Momjian (pgman@candle.pha.pa.us) wrote:
So you don't have all the *_r functions, and your non-*_r functions
aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
Exactly. Most other threading works though. :)
--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
The only source of knowledge is experience...
Bruce Momjian writes:
Both gethostbyname() and getpwuid() have no _r equivalents on
FreeBSD-STABLE, ergo no thread-safe functions of these.So you don't have all the *_r functions, and your non-*_r functions
aren't thread-safe. Should we disable theading on FreeBSD? Seems so.
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.
--
Peter Eisentraut peter_e@gmx.net
-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.
Having libc_r is not a guarantee that all functions of libc are
represented in that library as thread-safe functions.
gethostbyname_r() is a notable reentrant function which is absent in
FreeBSD.
--
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
Character is what you are in the dark...
Jeroen Ruigrok/asmodai wrote:
-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.
A thread-safe library has a per-thread errno value (i.e. errno is a
#define to a function call), thread-safe io buffers for stdio, etc. Some
of these changes cause a noticable overhead, thus a seperate library for
those users who want to avoid that overhead.
Reentrancy is independant from _r: If you look at the prototype of
gethostbyname(), it's just not possible to make that thread safe with
reasonable effort - the C library would have to keep one buffer per
thread around.
Having libc_r is not a guarantee that all functions of libc are
represented in that library as thread-safe functions.gethostbyname_r() is a notable reentrant function which is absent in
FreeBSD.
Is there a thread-safe alternate to gethostbyname() for FreeBSD?
--
Manfred
Manfred Spraul wrote:
Jeroen Ruigrok/asmodai wrote:
-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.A thread-safe library has a per-thread errno value (i.e. errno is a
#define to a function call), thread-safe io buffers for stdio, etc. Some
of these changes cause a noticable overhead, thus a seperate library for
those users who want to avoid that overhead.Reentrancy is independant from _r: If you look at the prototype of
gethostbyname(), it's just not possible to make that thread safe with
reasonable effort - the C library would have to keep one buffer per
thread around.
See the top of src/port/thread.c --- that's exactly what is does (keep
one buffer per thread around).
* Threading sometimes requires specially-named versions of functions
* that return data in static buffers, like strerror_r() instead of
* strerror(). Other operating systems use pthread_setspecific()
* and pthread_getspecific() internally to allow standard library
* functions to return static data to threaded applications.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Bruce Momjian wrote:
Manfred Spraul wrote:
Jeroen Ruigrok/asmodai wrote:
-On [20030908 23:52], Peter Eisentraut (peter_e@gmx.net) wrote:
Why would FreeBSD have a "library of thread-safe libc functions" (libc_r)
if the functions weren't thread-safe? I think the test is faulty.A thread-safe library has a per-thread errno value (i.e. errno is a
#define to a function call), thread-safe io buffers for stdio, etc. Some
of these changes cause a noticable overhead, thus a seperate library for
those users who want to avoid that overhead.Reentrancy is independant from _r: If you look at the prototype of
gethostbyname(), it's just not possible to make that thread safe with
reasonable effort - the C library would have to keep one buffer per
thread around.See the top of src/port/thread.c --- that's exactly what is does (keep
one buffer per thread around).* Threading sometimes requires specially-named versions of functions
* that return data in static buffers, like strerror_r() instead of
* strerror(). Other operating systems use pthread_setspecific()
* and pthread_getspecific() internally to allow standard library
* functions to return static data to threaded applications.
And that's exactly what src/tools/test_thread_funcs.c tests for.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
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 do support pthreads do
not necessarily provide thread-safe libc functions.
Is it possible to identify which functions are likely to be called by multiple
threads and create our own mutex-wrapper functions for them? Disabling
thread-safety seems pretty drastic simply because of a lack of getpwuid_r()
or thread-safe getpwuid(). Or do I misunderstand your concerns?
Regards, Philip.
$ uname -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your functions are _not_ all thread-safe
There are older _r functions, but they're deprecated as the non _r are now
thread-safe.
$ uname -a
SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
$ gcc -lpthread -lnsl test.c # this works
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
getpwduid_r provided
gethostbyname_r not provided
FreeBSD 5.1 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
manpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."
FreeBSD 4.8 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
manpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."
Linux 2.4.18-3 (i686)
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safe
manpage notes "The functions gethostbyname() and gethostbyaddr() may return
pointers to static data, which may be over-
written by later calls. Copying the struct hostent does not suffice,
since it contains pointers - a deep
copy is required.
Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().
These return 0 on success and
nonzero on error. The result of the call is now stored in the
struct with address ret. After the call,
*result will be NULL on error or point to the result on success.
Auxiliary data is stored in the buffer
buf of length buflen. (If the buffer is too small, these functions
will return ERANGE.) No global vari-
able h_errno is modified, but the address of a variable in which to
store error numbers is passed in
h_errnop."
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 awful lot of platforms that do support pthreads do
not necessarily provide thread-safe libc functions.
I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
below.
Is it possible to identify which functions are likely to be called by multiple
threads and create our own mutex-wrapper functions for them? Disabling
thread-safety seems pretty drastic simply because of a lack of getpwuid_r()
or thread-safe getpwuid(). Or do I misunderstand your concerns?
I am starting to think your approach is the only way to go --- I was
thinking of it for FreeBSD, but now, with these additional platforms, it
seems almost a requirement.
We would have to get some thread mutex, make the function call, copy the
return values into the passed pointer, and release the mutex? Do we
test to see if we are in thread mode before doing the locking? Is that
test even possible or desirable?
Seems we will need to rename the config variable to be
NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
*_r function, and fall back to the mutex if both settings are false.
This part has me concerned too:
Copying the struct hostent does not suffice, since it contains
pointers - a deep copy is required.
Would someone with thread mutex experience assist me?
---------------------------------------------------------------------------
Regards, Philip.
$ uname -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your functions are _not_ all thread-safeThere are older _r functions, but they're deprecated as the non _r are now
thread-safe.$ uname -a
SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
$ gcc -lpthread -lnsl test.c # this works
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safegetpwduid_r provided
gethostbyname_r not providedFreeBSD 5.1 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."FreeBSD 4.8 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."Linux 2.4.18-3 (i686)
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "The functions gethostbyname() and gethostbyaddr() may return
pointers to static data, which may be over-
written by later calls. Copying the struct hostent does not suffice,
since it contains pointers - a deep
copy is required.Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().
These return 0 on success and
nonzero on error. The result of the call is now stored in the
struct with address ret. After the call,
*result will be NULL on error or point to the result on success.
Auxiliary data is stored in the buffer
buf of length buflen. (If the buffer is too small, these functions
will return ERANGE.) No global vari-
able h_errno is modified, but the address of a variable in which to
store error numbers is passed in
h_errnop."
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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 the function call, copy the
return values into the passed pointer, and release the mutex? Do we
test to see if we are in thread mode before doing the locking? Is that
test even possible or desirable?
I guess as with the threading stuff in ECPG:
#ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
pthread_mutex_lock(&my_mutex)
#endif
/* do stuff */
#ifdef SOME_DEF
pthread_mutex_unlock(&my_mutex)
#endif
Seems we will need to rename the config variable to be
NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
*_r function, and fall back to the mutex if both settings are false.
Yeah, or you could just always use the wrapper and not try to do all the test
in configure... doubtless less efficient, but maybe better for the mental
health...
This part has me concerned too:
Copying the struct hostent does not suffice, since it contains
pointers - a deep copy is required.Would someone with thread mutex experience assist me?
Ummm... replace /* do stuff /* above with a deep copy of the hostent struct.
I'll give that a shot if you like.
Regards, Philip.
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 middle name. ;-)
Anyway, the output was:
$ uname -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your functions are _not_ all thread-safe
What that says is that getpwuid doesn't return the same pointer value
for two calls even in the same thread. C comments say:
* This program first tests to see if each function returns a constant
* memory pointer within the same thread, then, assuming it does, tests
* to see if the pointers are different for different threads. If they
* are, the function is thread-safe.
So my guess is that OSF returns a pointer into a pre-allocated area that
it allocates for every user in the database, or at least on every call
to a username --- perhaps it creates a hash in libc indexed by username
--- anyway, it is probably threadsafe, but strerror isn't, so we are
dead anyway. :-)We would have to get some thread mutex, make the function call, copy the
return values into the passed pointer, and release the mutex? Do we
test to see if we are in thread mode before doing the locking? Is that
test even possible or desirable?I guess as with the threading stuff in ECPG:
#ifdef SOME_DEF (sorry, have to check the ECPG source on that one)
pthread_mutex_lock(&my_mutex)
#endif/* do stuff */
#ifdef SOME_DEF
pthread_mutex_unlock(&my_mutex)
#endif
Yep. Ugly but required.
Seems we will need to rename the config variable to be
NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
*_r function, and fall back to the mutex if both settings are false.Yeah, or you could just always use the wrapper and not try to do all the test
in configure... doubtless less efficient, but maybe better for the mental
health...
True. In fact, on platforms with non-*_r functions that are
thread-safe, those locks are already done in libc anyway. The problem
is that on platforms that don't have non *_r thread-safe, and don't
have all the *_r functions, we would be adding overhead to libpq that
isn't already part of libc on that platform, and that seems wrong to me.
We might have to produce a libpq_r and ecpg_r (yuck) on those platforms.
Double-yuck.
This part has me concerned too:
Copying the struct hostent does not suffice, since it contains
pointers - a deep copy is required.Would someone with thread mutex experience assist me?
Ummm... replace /* do stuff /* above with a deep copy of the hostent struct.
I'll give that a shot if you like.
Tripple-yuck. :-)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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, have to check the ECPG source on that one)
pthread_mutex_lock(&my_mutex)
#endif/* do stuff */
#ifdef SOME_DEF
pthread_mutex_unlock(&my_mutex)
#endifYep. Ugly but required.
Could be worse - at least creating a wrapper function keeps the
aesthetically-offensive code away from most of the code, and everyone else
could just call pg_gethostbyname() or whatever...
Yeah, or you could just always use the wrapper and not try to do all the
test in configure... doubtless less efficient, but maybe better for the
mental health...True. In fact, on platforms with non-*_r functions that are
thread-safe, those locks are already done in libc anyway. The problem
is that on platforms that don't have non *_r thread-safe, and don't
have all the *_r functions, we would be adding overhead to libpq that
isn't already part of libc on that platform, and that seems wrong to me.
Double-yuck.
No, correct me if I'm wrong, but the #ifdef'd code is removed by the
pre-processor, so platforms without thread support would gain only the
overhead of a single function call? That doesn't seem so steep.
The actual copying of the structs wouldn't be needed in this case, so handle
that like:
#ifdef SOME_DEF
/* copy structure and set return pointer to this copy /*
#else
/* set return pointer to global buffer */
#endif
It's only a penalty for platforms with thread-safe functions called within the
mutex_locked section... and if we're talking about functions like
gethostbyname() (which may well be making a network call to a DNS server) I
doubt the second mutex_lock would be a noticeable penalty.
Making copies of structures is some penalty, that's true... I might try some
timings to see how much of a penalty. Are these functions likely to see such
heavy use that the additional times are a problem?
We might have to produce a libpq_r and ecpg_r (yuck) on those platforms.
I beg you, stay away from this idea! Informix does this, and it isn't pretty.
I have the core files to prove it.
Ummm... replace /* do stuff /* above with a deep copy of the hostent
struct. I'll give that a shot if you like.Tripple-yuck. :-)
Hey, are you impugning my coding style? If so, you'll have to join the queue.
:-)
Do you want me to have a try at the gethostbyname() wrappers, or is it going
to be a waste of time?
Regards, Philip.
Bruce Momjian <pgman@candle.pha.pa.us> 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. Persons unhappy with this labeling must
take it up with their OS developers, not us.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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. Persons unhappy with this labeling must
take it up with their OS developers, not us.
Yep, that is one clear option. It would certainly make my job easier.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> 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. Persons unhappy with this labeling must
take it up with their OS developers, not us.
We do actually have a way to report OS thread failure to the user --- if
they ask for --enable-thread-safety, we just throw an error.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073On 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 and move on.
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 what else? MacOS X?
Persons unhappy with this labeling must
take it up with their OS developers, not us.
Surely the development of PostgreSQL has seen lots of platform shortcomings
found and worked-around? Why not this as well?
Are these non-threadsafe functions really going to be so heavily-used that we
can't live with the wrappers? I mean, AFAIK these threading issues are only
in ECPG and libpq - it's not like re-writing the backend code is required.
Philip Yarra <philip@utiba.com> 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 we should mark it
not-thread-safe and move on.
This would be a pretty short list unless I count wrong!
If it's a short list, then it's a short list.
Surely the development of PostgreSQL has seen lots of platform shortcomings
found and worked-around? Why not this as well?
Because we are not working in a vacuum. 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. When the
platform's libc has more thread-safety holes than the average block of
swiss cheese, there is no reason that I can see for us to expend effort
on workarounds that only fix libpq's usage. Any app that might want to
use libpq is going to hit those same bugs, and so in the long run the
only useful answer is for the platform to fix its libc.
The real bottom line here is: who is going to try to build threaded
apps on platforms with un-thread-safe libc? And why should we be the
ones to try to save them from suffering the pain they deserve? We have
enough problems of our own to deal with...
regards, tom lane
Philip Yarra <philip@utiba.com> 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 what else? MacOS X?
Uhm I stopped reading this thread a while back. Linux has all the reentrant
functions required like strerror_r, getpwnam_r, etc. Why do we think it
wouldn't pass?
Are these non-threadsafe functions really going to be so heavily-used that we
can't live with the wrappers? I mean, AFAIK these threading issues are only
in ECPG and libpq - it's not like re-writing the backend code is required.
It's only libpq and ECPG where thread-safety is at all an issue.
--
greg
Tom wrote:
At this point it should move to pghackers, I think.
(responding to a patch for ISO 8601 "Time Intervals" in pgsql-patches)
Looks like I'll take a shot at more broadly hacking the postgresql
time interval code. Before doing so, I wanted to ask opinions
regarding what the "right" behavior is of various timestamp/interval
operations.
I think the best way ask the specific questions is to ask a
quiz highlighting some of the unexpected behavior with the
current implementation.
1. What should this expression give:
select '0.01 years'::interval > '0.01 months'::interval;
A) False - the first is 0 months, the second is about 25000 seconds.
B) True - one is about 300000 seconds, the other is about 25000.
C) An error - fractional dates are asking for trouble.
D) Something else -- please tell me.
2. If I have this expression:
select '2003-01-31'::timestamp + '2 months',
'2003-01-31'::timestamp + '1 month' + '1 month'
'2003-01-31'::timestamp + '0.5 months'::interval * 4;
would I expect the results to:
A) All be different.
The first is 89 days, (Mar 31, because it's the last day of Mar).
the second 86 days, (Mar 28, because February clips the date)
and the third 90 days (Apr 01, because half-months are 15 days).
B) All should be the same.
Two months is two months no matter how you slice it.
C) An error - with fractional months being undefined.
D) Something else -- please tell me.
3. Or odd behavior with time-zones.
select '2002-01-01'::timestamp + '6 months',
'2002-01-01'::timestamp + '181 days',
'2002-01-01'::timestamp + '4344 hours';
Note that those months have 181 days, and 4344 is
181 days * 24 hours. I would expect:
A) The first one represents midnight on 2002-07-01.
The second two one hour different (1AM) to make up
for the missed hour on daylight savings.
B) The first two expressions (Days and Months) are both
"calendar time" so they'd both be midnight.
Only the third one would be 1AM.
D) Something else -- please tell me.
To give away the answers...
(A) Appears to be current behavior.
(B) Is one possible proposal that started being discussed on PGPatches.
(C) Is one other possible proposal that mentioned on PGPatches.
(D) Would be appreciated.
I'd love to hear what any specs, especially the SQL spec
has to say for it.
Ron
On Wed, Sep 10, 2003 at 11:48:58 -0700,
Ron Mayer <ron@intervideo.com> wrote:
Looks like I'll take a shot at more broadly hacking the postgresql
time interval code. Before doing so, I wanted to ask opinions
regarding what the "right" behavior is of various timestamp/interval
operations.
Can you document which part of a mixed interval (with both months and
seconds parts) gets added first to a timestamp? I haven't ever run
accross anything which says which gets done first.
Bruno wrote:
Can you document which part of a mixed interval (with both months and
seconds parts) gets added first to a timestamp? I haven't ever run
across anything which says which gets done first.
In the existing code, the sql spec, or the proposed implementation?
In the existing code, I think everything with "+" gets done
in in the same order (left-to-right?), regardless of if the
fields are timestamps or intervals.
This leads to cool crazy behavior like getting different
answers for this:
logs=# select '.5 months'::interval +
'.5 months'::interval +
'2003-01-01'::timestamp;
?column?
---------------------
2003-01-01 00:00:00
(1 row)
logs=# select '2003-01-01'::timestamp +
'.5 months'::interval +
'.5 months'::interval;
?column?
------------------------
2003-01-31 00:00:00-08
(1 row)
With addition not being commutative, all sorts of pain can result.
The thing I'm proposing, is to define a form of time-math
that is as consistant as possible.
There are at least two reasonable ways of doing this -- using
calendar time, or using absolute time.
ISO 8601 makes such distinctions between "day" which it
defines as 24 hours, and "calendar day" which it defines
as 24 hours +/- leap minutes and seconds.
The way this would work, we could:
(1) Using calendar time:
When doing math on 'intervals' and 'timestamps', we would keep
the fundementally different units separate until the end.
This means keeping separate track of
years & months in units of months
weeks & days in units of days
hours and less in units of seconds
through out the calculation.
This means you could have an intervals of '.5 months' without
it converting to 15 days until the very end.
(2) Using absolute time:
Interval math could take a odd shortcut of turning everything
to seconds early in the calculation and converting back at
the end.
I actually think each of the two are useful for different applications;
so I'm really tempted to create a GUC parameter
date_math = 'absolute' or 'calendar'
to select between the two.
On Wed, Sep 10, 2003 at 15:43:56 -0700,
Ron Mayer <ron@intervideo.com> wrote:
Bruno wrote:
Can you document which part of a mixed interval (with both months and
seconds parts) gets added first to a timestamp? I haven't ever run
across anything which says which gets done first.In the existing code, the sql spec, or the proposed implementation?
In whatever is going to get implemented.
In the existing code, I think everything with "+" gets done
in in the same order (left-to-right?), regardless of if the
fields are timestamps or intervals.
That isn't what I was asking about. An interval has two parts. One
part is the number of months in the interval and the other part is
the number of seconds (or perhaps milliseconds). Often a single interval
will only have one of these parts be nonzero. However if both parts are
nonzero it makes a difference in which part gets added first.
For example '2003-02-28'::date + '1 month 1 day'::interval might
be either 2003-03-29 or 2003-04-01. In 7.4 it is currently 2003-03-29,
but since it isn't documented it isn't clear if that will be true
in future versions.
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 that don't fall into that short list. It can be done.
Thus far we have had to use Sybase or Informix because they do support
thread-safe C interfaces.
Any app that might want to
use libpq is going to hit those same bugs, and so in the long run the
only useful answer is for the platform to fix its libc.
The useful answer (so far) is to not use PostgreSQL for these applications,
but to stick with a database that does support a threadsafe C interface. I
think that's a pity.
I agree, it would make life easier if vendors supported threadsafe libc
functions.
The real bottom line here is: who is going to try to build threaded
apps on platforms with un-thread-safe libc?
The company I work for. I got involved in this issue so we could port from
Sybase and Informix to PostgreSQL. I assume there are other people out there
who'd be interested as well.
And why should we be the
ones to try to save them from suffering the pain they deserve?
1) Leave users to cope with their own code issues, but make sure the
database's C interface isn't one of them.
2) Because it's good enough for (Oracle|Informix|Sybase)
So moving forward: do we try Bruce's idea of libpq_r and ecpg_r? If people
want to risk the overhead of wrapped libc calls, they can build the threaded
lib versions and link against those. Would that be acceptable to people?
Regards, Philip.
Bruno wrote:
...An interval has two parts... the number of months...and...the number of
seconds...if both parts are nonzero it makes a difference in which part
gets added first. For example '2003-02-28'::date + '1 month 1 day'::interval
might be either 2003-03-29 or 2003-04-01. In 7.4 it is currently 2003-03-29,
Ah.. I understand.
At least one other application that does date math, MSFT Excel
also claims 2003-03-29 when I use the expression
"=DATE(YEAR(B3),MONTH(B3)+1,DAY(B3)+1)"
so I think that's a reasonable rule to keep.
Anyone, please let me know if there are good reasons such as
standards or other major applications that behave otherwise.
Thanks for this other interesting case that I need to worry about!
And yes, I'll document it as well. :-)
Ron
PS: I'm not receiving some emails I send to hackers. If you
need a timely answer please cc me -- though I will follow
the thread on archives as well to catch anything I miss.
Hi,
after Beta1 I'd reported problems in the regression tests under Digital
Unix/Tru64. Unfortunately I had no time to report about my tests and to
check Beta2 before now.
Beta2 builds fine on Digital Unix 4.0G:
template1=# SELECT version();
version
-------------------------------------------------------------------
PostgreSQL 7.4beta2 on alphaev67-dec-osf4.0g, compiled by cc -std
and regression tests are ok.
Under Beta1 the regression tests failed in random ways: I've run tens of
sets, with a number of errors ranging from 0 to 8-9. Almost any test
have failed once or more, and I could not recognise any apparent
pattern. I tend to put the blame on the test themselves rather that the
database, or maybe to the environment of the tests.
--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://village.albourne.com
Nicosia, Cyprus phone: +357-22755750
"It is more complicated than you think"
-- The Eighth Networking Truth from RFC 1925
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
Thanks.
---------------------------------------------------------------------------
Christopher Kings-Lynne wrote:
FreeBSD 4.8/i386:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeChris
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Kurt Roeckx" <Q@ping.be>
Cc: <pgsql-hackers@postgresql.org>
Sent: Thursday, September 04, 2003 6:07 AM
Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...)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 getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeFrom a Linux system with libc5:
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safeThanks.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.
I have access to one NetBSD system on an Alpha:
$ uname -a
NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun 1
20:44:15 CDT 2003
eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/arch/
alpha/compile/MILO alpha
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthread'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthreads'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ locate pthread.h
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
-- Start of PGP signed section.
--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.I have access to one NetBSD system on an Alpha:
$ uname -a
NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun 1
20:44:15 CDT 2003
eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/arch/
alpha/compile/MILO alpha
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthread'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthreads'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ locate pthread.h
Wow, that is strange. Someone else told me NetBSD supports threads, and
doesn't need any special compile flags, but of course, it has to have
pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
an old OS.
Can you compile if you remove the pthread.h include? No special compile
flags should be required.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Friday, September 12, 2003 13:03:33 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
-- Start of PGP signed section.--On Friday, September 12, 2003 12:18:52 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:I need someone running NetBSD to read the top of
src/tools/test_thread_funcs.c and compile and run that function and
report the results.I have access to one NetBSD system on an Alpha:
$ uname -a
NetBSD milo.cirr.com 1.6.1_STABLE NetBSD 1.6.1_STABLE (MILO) #1: Sun Jun
1 20:44:15 CDT 2003
eric@milo.cirr.com:/rmt/.amd/egsner/root/work/eric/NetBSD-1.6/src/sys/ar
ch/ alpha/compile/MILO alpha
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthread -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthread'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ cc -O -pthreads -o test_thread_funcs test_thread_funcs.c
cc: unrecognized option `-pthreads'
test_thread_funcs.c:27: pthread.h: No such file or directory
$ locate pthread.hWow, that is strange. Someone else told me NetBSD supports threads, and
doesn't need any special compile flags, but of course, it has to have
pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
an old OS.Can you compile if you remove the pthread.h include? No special compile
flags should be required.
Nope......
$ vi test*
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c: In function `main':
test_thread_funcs.c:50: `pthread_t' undeclared (first use in this function)
test_thread_funcs.c:50: (Each undeclared identifier is reported only once
test_thread_funcs.c:50: for each function it appears in.)
test_thread_funcs.c:50: parse error before `thread1'
test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
$
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote:
Wow, that is strange. Someone else told me NetBSD supports threads, and
doesn't need any special compile flags, but of course, it has to have
pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
an old OS.Can you compile if you remove the pthread.h include? No special compile
flags should be required.Nope......
$ vi test*
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c: In function `main':
test_thread_funcs.c:50: `pthread_t' undeclared (first use in this function)
test_thread_funcs.c:50: (Each undeclared identifier is reported only once
test_thread_funcs.c:50: for each function it appears in.)
test_thread_funcs.c:50: parse error before `thread1'
test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
$
There a pthrads package you have to install, (pkgsrc/devel/pth):
Seems 2.0 will have native threads support. Now, how does this relate
to libc's thread-safeness?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073--On Friday, September 12, 2003 13:30:38 -0400 Bruce Momjian
<pgman@candle.pha.pa.us> wrote:
Larry Rosenman wrote:
Wow, that is strange. Someone else told me NetBSD supports threads,
and doesn't need any special compile flags, but of course, it has to
have pthread.h to support threads. NetBSD 1.6.1 is very current, so
it isn't an old OS.Can you compile if you remove the pthread.h include? No special
compile flags should be required.Nope......
$ vi test*
$ cc -O -o test_thread_funcs test_thread_funcs.c
test_thread_funcs.c: In function `main':
test_thread_funcs.c:50: `pthread_t' undeclared (first use in this
function) test_thread_funcs.c:50: (Each undeclared identifier is
reported only once test_thread_funcs.c:50: for each function it appears
in.)
test_thread_funcs.c:50: parse error before `thread1'
test_thread_funcs.c:59: `thread1' undeclared (first use in this function)
test_thread_funcs.c:60: `thread2' undeclared (first use in this function)
$There a pthrads package you have to install, (pkgsrc/devel/pth):
http://groups.google.com/groups?q=netbsd+threads+pthread.h&start=30&hl=e
n&lr=&ie=UTF-8&selm=bhio3i%24cnp%241%40FreeBSD.csie.NCTU.edu.tw&rnum=35Seems 2.0 will have native threads support. Now, how does this relate
to libc's thread-safeness?
Bruce,
I cc'd you on a note from milo.cirr.com's owner.
That may shed some light.
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
<quote who="Bruce Momjian">
Wow, that is strange. Someone else told me NetBSD supports threads, and
doesn't need any special compile flags, but of course, it has to have
pthread.h to support threads. NetBSD 1.6.1 is very current, so it isn't
an old OS.
NetBSD-1.6.1 doesn't have native thread. NetBSD-current has it though.
Thomas T. Thai
[ 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 exist (configure test)
do our own locking and copying of non-threadsafe functions
With Solaris, FreeBSD, and OSF failing our existing setup, the last
option of doing our own locking and copying seemed necessary. The good
news is that this is used only if another method can not be found. I
used the 'bind' source code as an example of how to do this.
Patch sent to patches list.
---------------------------------------------------------------------------
Bruce Momjian wrote:
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 awful lot of platforms that do support pthreads do
not necessarily provide thread-safe libc functions.I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
below.Is it possible to identify which functions are likely to be called by multiple
threads and create our own mutex-wrapper functions for them? Disabling
thread-safety seems pretty drastic simply because of a lack of getpwuid_r()
or thread-safe getpwuid(). Or do I misunderstand your concerns?I am starting to think your approach is the only way to go --- I was
thinking of it for FreeBSD, but now, with these additional platforms, it
seems almost a requirement.We would have to get some thread mutex, make the function call, copy the
return values into the passed pointer, and release the mutex? Do we
test to see if we are in thread mode before doing the locking? Is that
test even possible or desirable?Seems we will need to rename the config variable to be
NON_REENTRANT_FUNC_NAMES_THREADSAFE, and add configure checks for each
*_r function, and fall back to the mutex if both settings are false.This part has me concerned too:
Copying the struct hostent does not suffice, since it contains
pointers - a deep copy is required.Would someone with thread mutex experience assist me?
---------------------------------------------------------------------------
Regards, Philip.
$ uname -a
OSF1 hostname V4.0 1229 alpha
$ ./a.out
Your getpwuid() changes the static memory area between calls
Your strerror() is _not_ thread-safe
Your functions are _not_ all thread-safeThere are older _r functions, but they're deprecated as the non _r are now
thread-safe.$ uname -a
SunOS hostname 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-4
$ gcc -lpthread -lnsl test.c # this works
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safegetpwduid_r provided
gethostbyname_r not providedFreeBSD 5.1 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."FreeBSD 4.8 (i386)
$ cc -pthread test.c
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "BUGS
These functions use static data storage; if the data is needed for future
use, it should be copied before any subsequent calls overwrite it."Linux 2.4.18-3 (i686)
$ ./a.out
Your gethostbyname() is _not_ thread-safe
Your getpwuid() is _not_ thread-safe
Your functions are _not_ all thread-safemanpage notes "The functions gethostbyname() and gethostbyaddr() may return
pointers to static data, which may be over-
written by later calls. Copying the struct hostent does not suffice,
since it contains pointers - a deep
copy is required.Glibc2 also has reentrant versions gethostbyname_r() and gethostbyname2_r().
These return 0 on success and
nonzero on error. The result of the call is now stored in the
struct with address ret. After the call,
*result will be NULL on error or point to the result on success.
Auxiliary data is stored in the buffer
buf of length buflen. (If the buffer is too small, these functions
will return ERANGE.) No global vari-
able h_errno is modified, but the address of a variable in which to
store error numbers is passed in
h_errnop."-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Attachments:
/bjm/difftext/plainDownload
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.287
diff -c -c -r1.287 configure.in
*** configure.in 12 Sep 2003 16:10:26 -0000 1.287
--- configure.in 13 Sep 2003 14:47:43 -0000
***************
*** 1031,1047 ****
# One trick here is that if we don't call AC_CHECK_FUNCS, the
# functions are marked "not found", which is perfect.
#
! if test "$enable_thread_safety" = yes -a "$NEED_REENTRANT_FUNC_NAMES" = yes ; then
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $THREAD_CFLAGS"
LIBS="$LIBS $THREAD_LIBS"
! AC_CHECK_FUNC(strerror_r,
! [], [AC_MSG_ERROR([strerror_r not found, required on this platform for --enable-thread-safety])])
! AC_CHECK_FUNC(getpwuid_r,
! [], [AC_MSG_ERROR([getpwuid_r not found, required on this platform for --enable-thread-safety])])
! AC_CHECK_FUNC(gethostbyname_r,
! [], [AC_MSG_ERROR([gethostbyname_r not found, required on this platform for --enable-thread-safety])])
CFLAGS="$_CFLAGS"
LIBS="$_LIBS"
fi
--- 1031,1042 ----
# One trick here is that if we don't call AC_CHECK_FUNCS, the
# functions are marked "not found", which is perfect.
#
! if test "$enable_thread_safety" = yes -a "$NEED_REENTRANT_FUNCS" = yes ; then
_CFLAGS="$CFLAGS"
_LIBS="$LIBS"
CFLAGS="$CFLAGS $THREAD_CFLAGS"
LIBS="$LIBS $THREAD_LIBS"
! AC_CHECK_FUNCS([strerror_r getpwuid_r gethostbyname_r])
CFLAGS="$_CFLAGS"
LIBS="$_LIBS"
fi
Index: src/include/port.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/port.h,v
retrieving revision 1.13
diff -c -c -r1.13 port.h
*** src/include/port.h 5 Sep 2003 17:43:39 -0000 1.13
--- src/include/port.h 13 Sep 2003 14:47:46 -0000
***************
*** 114,124 ****
#ifndef WIN32
extern int pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer,
! size_t buflen, struct passwd ** result);
#endif
extern int pqGethostbyname(const char *name,
! struct hostent * resbuf,
! char *buf, size_t buflen,
! struct hostent ** result,
int *herrno);
--- 114,124 ----
#ifndef WIN32
extern int pqGetpwuid(uid_t uid, struct passwd * resultbuf, char *buffer,
! size_t buflen, struct passwd **result);
#endif
extern int pqGethostbyname(const char *name,
! struct hostent *resultbuf,
! char *buffer, size_t buflen,
! struct hostent **result,
int *herrno);
Index: src/port/thread.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/port/thread.c,v
retrieving revision 1.6
diff -c -c -r1.6 thread.c
*** src/port/thread.c 5 Sep 2003 17:43:40 -0000 1.6
--- src/port/thread.c 13 Sep 2003 14:47:47 -0000
***************
*** 14,25 ****
#include "postgres.h"
/*
* Threading sometimes requires specially-named versions of functions
* that return data in static buffers, like strerror_r() instead of
* strerror(). Other operating systems use pthread_setspecific()
* and pthread_getspecific() internally to allow standard library
! * functions to return static data to threaded applications.
*
* Additional confusion exists because many operating systems that
* use pthread_setspecific/pthread_getspecific() also have *_r versions
--- 14,30 ----
#include "postgres.h"
+ #include <pthread.h>
+ #include <sys/types.h>
+ #include <pwd.h>
+
/*
* Threading sometimes requires specially-named versions of functions
* that return data in static buffers, like strerror_r() instead of
* strerror(). Other operating systems use pthread_setspecific()
* and pthread_getspecific() internally to allow standard library
! * functions to return static data to threaded applications. And some
! * operating systems have neither, meaning we have to do our own locking.
*
* Additional confusion exists because many operating systems that
* use pthread_setspecific/pthread_getspecific() also have *_r versions
***************
*** 36,46 ****
* doesn't have strerror_r(), so we can't fall back to only using *_r
* functions for threaded programs.
*
! * The current setup is to assume either all standard functions are
! * thread-safe (NEED_REENTRANT_FUNC_NAMES=no), or the operating system
! * requires reentrant function names (NEED_REENTRANT_FUNC_NAMES=yes).
* Compile and run src/tools/test_thread_funcs.c to see if your operating
! * system requires reentrant function names.
*/
--- 41,55 ----
* doesn't have strerror_r(), so we can't fall back to only using *_r
* functions for threaded programs.
*
! * The current setup is to try threading in this order:
! *
! * use non-*_r function names if they are all thread-safe
! * (NEED_REENTRANT_FUNCS=no)
! * use *_r functions if they exist (configure test)
! * do our own locking and copying of non-threadsafe functions
! *
* Compile and run src/tools/test_thread_funcs.c to see if your operating
! * system has thread-safe non-*_r functions.
*/
***************
*** 51,64 ****
char *
pqStrerror(int errnum, char *strerrbuf, size_t buflen)
{
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
/* reentrant strerror_r is available */
/* some early standards had strerror_r returning char * */
strerror_r(errnum, strerrbuf, buflen);
! return (strerrbuf);
#else
/* no strerror_r() available, just use strerror */
! return strerror(errnum);
#endif
}
--- 60,86 ----
char *
pqStrerror(int errnum, char *strerrbuf, size_t buflen)
{
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_STRERROR_R)
/* reentrant strerror_r is available */
/* some early standards had strerror_r returning char * */
strerror_r(errnum, strerrbuf, buflen);
! return strerrbuf;
!
#else
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_STRERROR_R)
+ static pthread_mutex_t strerror_lock = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_lock(&strerror_lock);
+ #endif
+
/* no strerror_r() available, just use strerror */
! StrNCpy(strerrbuf, strerror(errnum), buflen);
!
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_STRERROR_R)
! pthread_mutex_unlock(&strerror_lock);
! #endif
!
! return strerrbuf;
#endif
}
***************
*** 71,77 ****
pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result)
{
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
/*
* Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
* getpwuid_r(uid, resultbuf, buffer, buflen)
--- 93,99 ----
pqGetpwuid(uid_t uid, struct passwd *resultbuf, char *buffer,
size_t buflen, struct passwd **result)
{
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETPWUID_R)
/*
* Early POSIX draft of getpwuid_r() returns 'struct passwd *'.
* getpwuid_r(uid, resultbuf, buffer, buflen)
***************
*** 79,87 ****
--- 101,152 ----
*/
/* POSIX version */
getpwuid_r(uid, resultbuf, buffer, buflen, result);
+
#else
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)
+ static pthread_mutex_t getpwuid_lock = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_lock(&getpwuid_lock);
+ #endif
+
/* no getpwuid_r() available, just use getpwuid() */
*result = getpwuid(uid);
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETPWUID_R)
+
+ /* Use 'buffer' memory for storage of strings used by struct passwd */
+ if (*result &&
+ strlen((*result)->pw_name) + 1 +
+ strlen((*result)->pw_passwd) + 1 +
+ strlen((*result)->pw_gecos) + 1 +
+ /* skip class if it exists */
+ strlen((*result)->pw_dir) + 1 +
+ strlen((*result)->pw_shell) + 1 <= buflen)
+ {
+ memcpy(resultbuf, *result, sizeof(struct passwd));
+ strcpy(buffer, (*result)->pw_name);
+ resultbuf->pw_name = buffer;
+ buffer += strlen(resultbuf->pw_name) + 1;
+ strcpy(buffer, (*result)->pw_passwd);
+ resultbuf->pw_passwd = buffer;
+ buffer += strlen(resultbuf->pw_passwd) + 1;
+ strcpy(buffer, (*result)->pw_gecos);
+ resultbuf->pw_gecos = buffer;
+ buffer += strlen(resultbuf->pw_gecos) + 1;
+ strcpy(buffer, (*result)->pw_dir);
+ resultbuf->pw_dir = buffer;
+ buffer += strlen(resultbuf->pw_dir) + 1;
+ strcpy(buffer, (*result)->pw_shell);
+ resultbuf->pw_shell = buffer;
+ buffer += strlen(resultbuf->pw_shell) + 1;
+
+ *result = resultbuf;
+ }
+ else
+ *result = NULL;
+
+ pthread_mutex_unlock(&getpwuid_lock);
+ #endif
#endif
return (*result == NULL) ? -1 : 0;
}
***************
*** 93,119 ****
*/
int
pqGethostbyname(const char *name,
! struct hostent *resbuf,
! char *buf, size_t buflen,
struct hostent **result,
int *herrno)
{
! #if defined(USE_THREADS) && defined(NEED_REENTRANT_FUNC_NAMES)
/*
* broken (well early POSIX draft) gethostbyname_r() which returns
* 'struct hostent *'
*/
! *result = gethostbyname_r(name, resbuf, buf, buflen, herrno);
return (*result == NULL) ? -1 : 0;
#else
/* no gethostbyname_r(), just use gethostbyname() */
*result = gethostbyname(name);
if (*result != NULL)
return 0;
else
- {
- *herrno = h_errno;
return -1;
- }
#endif
}
--- 158,258 ----
*/
int
pqGethostbyname(const char *name,
! struct hostent *resultbuf,
! char *buffer, size_t buflen,
struct hostent **result,
int *herrno)
{
! #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && defined(HAVE_GETHOSTBYNAME_R)
/*
* broken (well early POSIX draft) gethostbyname_r() which returns
* 'struct hostent *'
*/
! *result = gethostbyname_r(name, resbuf, buffer, buflen, herrno);
return (*result == NULL) ? -1 : 0;
+
#else
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+ static pthread_mutex_t gethostbyname_lock = PTHREAD_MUTEX_INITIALIZER;
+ pthread_mutex_lock(&gethostbyname_lock);
+ #endif
+
/* no gethostbyname_r(), just use gethostbyname() */
*result = gethostbyname(name);
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+
+ /*
+ * Use 'buffer' memory for storage of structures used by struct hostent.
+ * The layout is:
+ *
+ * addr pointers
+ * alias pointers
+ * addr structures
+ * alias structures
+ * name
+ */
+ if (*result)
+ {
+ int i, pointers = 2 /* for nulls */, len = 0;
+ char **pbuffer;
+
+ for (i = 0; (*result)->h_addr_list[i]; i++, pointers++)
+ len += (*result)->h_length;
+ for (i = 0; (*result)->h_aliases[i]; i++, pointers++)
+ len += (*result)->h_length;
+
+ if (MAXALIGN(len) + pointers * sizeof(char *) + strlen((*result)->h_name) + 1 <= buflen)
+ {
+ memcpy(resultbuf, *result, sizeof(struct hostent));
+
+ pbuffer = (char **)buffer;
+ resultbuf->h_addr_list = pbuffer;
+ buffer += pointers * sizeof(char *);
+
+ for (i = 0; (*result)->h_addr_list[i]; i++, pbuffer++)
+ {
+ memcpy(buffer, (*result)->h_addr_list[i], (*result)->h_length);
+ resultbuf->h_addr_list[i] = buffer;
+ buffer += (*result)->h_length;
+ }
+ resultbuf->h_addr_list[i] = NULL;
+ pbuffer++;
+
+ resultbuf->h_aliases = pbuffer;
+
+ for (i = 0; (*result)->h_aliases[i]; i++, pbuffer++)
+ {
+ memcpy(buffer, (*result)->h_aliases[i], (*result)->h_length);
+ resultbuf->h_aliases[i] = buffer;
+ buffer += (*result)->h_length;
+ }
+ resultbuf->h_aliases[i] = NULL;
+ pbuffer++;
+
+ /* Place at end for cleaner alignment */
+ strcpy(buffer, (*result)->h_name);
+ resultbuf->h_name = buffer;
+ buffer += strlen(resultbuf->h_name) + 1;
+
+ *result = resultbuf;
+ }
+ else
+ *result = NULL;
+ }
+ #endif
+
+ if (*result != NULL)
+ *herrno = h_errno;
+
+ #if defined(FRONTEND) && defined(USE_THREADS) && defined(NEED_REENTRANT_FUNCS) && !defined(HAVE_GETHOSTBYNAME_R)
+ pthread_mutex_unlock(&gethostbyname_lock);
+ #endif
+
if (*result != NULL)
return 0;
else
return -1;
#endif
}
Index: src/template/bsdi
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/bsdi,v
retrieving revision 1.13
diff -c -c -r1.13 bsdi
*** src/template/bsdi 3 Sep 2003 20:54:20 -0000 1.13
--- src/template/bsdi 13 Sep 2003 14:47:47 -0000
***************
*** 11,14 ****
esac
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no # verified 4.3 2003-09-03
--- 11,14 ----
esac
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no # verified 4.3 2003-09-03
Index: src/template/freebsd
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/freebsd,v
retrieving revision 1.20
diff -c -c -r1.20 freebsd
*** src/template/freebsd 12 Sep 2003 16:49:34 -0000 1.20
--- src/template/freebsd 13 Sep 2003 14:47:47 -0000
***************
*** 4,11 ****
alpha*) CFLAGS="$CFLAGS -O" ;;
esac
! SUPPORTS_THREADS=no # 4.8, 5.1 2003-09-12
! NEED_REENTRANT_FUNC_NAMES=no
case $host_os in
freebsd2*|freebsd3*|freebsd4*)
--- 4,11 ----
alpha*) CFLAGS="$CFLAGS -O" ;;
esac
! SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=yes # 4.8, 5.1 2003-09-12
case $host_os in
freebsd2*|freebsd3*|freebsd4*)
Index: src/template/linux
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/linux,v
retrieving revision 1.13
diff -c -c -r1.13 linux
*** src/template/linux 3 Sep 2003 22:34:08 -0000 1.13
--- src/template/linux 13 Sep 2003 14:47:47 -0000
***************
*** 1,7 ****
CFLAGS=-O2
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=yes # verified glibc 2.1 2003-09-03
THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-lpthread"
--- 1,7 ----
CFLAGS=-O2
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=yes # verified glibc 2.1 2003-09-03
THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-lpthread"
Index: src/template/netbsd
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/netbsd,v
retrieving revision 1.10
diff -c -c -r1.10 netbsd
*** src/template/netbsd 16 Aug 2003 15:35:51 -0000 1.10
--- src/template/netbsd 13 Sep 2003 14:47:47 -0000
***************
*** 1,4 ****
CFLAGS='-O2 -pipe'
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no
--- 1,4 ----
CFLAGS='-O2 -pipe'
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no
Index: src/template/osf
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/osf,v
retrieving revision 1.7
diff -c -c -r1.7 osf
*** src/template/osf 16 Aug 2003 15:35:51 -0000 1.7
--- src/template/osf 13 Sep 2003 14:47:47 -0000
***************
*** 6,10 ****
fi
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no
THREAD_CFLAGS="-pthread"
--- 6,10 ----
fi
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no # 4.0 2003-09-13
THREAD_CFLAGS="-pthread"
Index: src/template/solaris
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/solaris,v
retrieving revision 1.2
diff -c -c -r1.2 solaris
*** src/template/solaris 21 Oct 2000 22:36:14 -0000 1.2
--- src/template/solaris 13 Sep 2003 14:47:47 -0000
***************
*** 4,6 ****
--- 4,11 ----
CC="$CC -Xa" # relaxed ISO C mode
CFLAGS=-v # -v is like gcc -Wall
fi
+
+ SUPPORTS_THREADS=yes
+ NEED_REENTRANT_FUNCS=yes # 5.6 2003-09-13
+ THREAD_CFLAGS="-pthread"
+
Index: src/template/unixware
===================================================================
RCS file: /cvsroot/pgsql-server/src/template/unixware,v
retrieving revision 1.21
diff -c -c -r1.21 unixware
*** src/template/unixware 3 Sep 2003 20:54:21 -0000 1.21
--- src/template/unixware 13 Sep 2003 14:47:47 -0000
***************
*** 10,14 ****
fi
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNC_NAMES=no # verified 7.1.3 2003-09-03
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"
--- 10,14 ----
fi
SUPPORTS_THREADS=yes
! NEED_REENTRANT_FUNCS=no # verified 7.1.3 2003-09-03
THREAD_CFLAGS="$THREAD_CFLAGS -D_REENTRANT"