Re: FreeBSD/i386 thread test

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(at)postgresql(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Larry Rosenman <ler(at)lerctr(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> Larry Rosenman <ler(at)lerctr(dot)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(at)lerctr(dot)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(at)gmx(dot)net

--On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
<peter_e(at)gmx(dot)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(at)lerctr(dot)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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Larry Rosenman wrote:
>
>
> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>
> > Larry Rosenman <ler(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Thursday, August 28, 2003 19:31:17 +0200 Peter Eisentraut
>> <peter_e(at)gmx(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Friday, August 29, 2003 23:00:46 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
>> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> > Larry Rosenman <ler(at)lerctr(dot)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(at)lerctr(dot)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(at)hub(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:
>
> > Larry Rosenman wrote:
> >>
> >>
> >> --On Thursday, August 28, 2003 01:06:46 -0400 Tom Lane
> >> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>
> >> > Larry Rosenman <ler(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

> 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"

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

--On Friday, August 29, 2003 23:25:06 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)hub(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)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(at)lerctr(dot)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(at)hub(dot)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(at)hub(dot)org> wrote:

>
>
> On Fri, 29 Aug 2003, Larry Rosenman wrote:
>
>>
>>
>> --On Saturday, August 30, 2003 00:19:49 -0300 "Marc G. Fournier"
>> <scrappy(at)hub(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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 @@
> 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"

'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(at)hub(dot)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 @@
>> 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"
>
> '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(at)lerctr(dot)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(at)hub(dot)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 @@
> >> 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"
> >
> > '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(at)hub(dot)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(at)lerctr(dot)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(at)hub(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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 ...

--On Saturday, August 30, 2003 00:17:41 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Saturday, August 30, 2003 01:09:54 -0300 "Marc G. Fournier"
>> <scrappy(at)hub(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Monday, September 01, 2003 12:35:43 -0400 Bruce Momjian
>> <pgman(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)hub(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)csl(dot)co(dot)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(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> Lee Kindness <lkindness(at)csl(dot)co(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Lee Kindness <lkindness(at)csl(dot)co(dot)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(at)lerctr(dot)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(at)csl(dot)co(dot)uk> wrote:

> "Larry Rosenman" <ler(at)lerctr(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Greg Stark <gsstark(at)mit(dot)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(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Greg Stark <gsstark(at)mit(dot)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(at)gmx(dot)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(at)gmx(dot)net

"Peter Eisentraut" <peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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 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.
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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tom Lane writes:
> Greg Stark <gsstark(at)mit(dot)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(at)mit(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Lee Kindness wrote:
> Tom Lane writes:
> > Greg Stark <gsstark(at)mit(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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 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.
> 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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 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.
>> 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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
>> <pgman(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)gmx(dot)net

--On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
<peter_e(at)gmx(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Larry Rosenman wrote:
>
>
> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
> <peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Tuesday, September 02, 2003 19:53:38 +0200 Peter Eisentraut
>> <peter_e(at)gmx(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:
>
>> Larry Rosenman wrote:
>>
>>>
>>>
>>> --On Tuesday, September 02, 2003 11:20:14 -0400 Bruce Momjian
>>> <pgman(at)candle(dot)pha(dot)pa(dot)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

>
> 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 want
>
>>
>> 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.

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Ok, 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(at)candle(dot)pha(dot)pa(dot)us>
> To: Olivier PRENANT <ohp(at)pyrenet(dot)fr>
> Cc: pgsql-hackers(at)postgresql(dot)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(at)pyrenet(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

ohp(at)pyrenet(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

>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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> ohp(at)pyrenet(dot)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(at)lerctr(dot)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(at)lerctr(dot)org>
> To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, ohp(at)pyrenet(dot)fr
> Cc: pgsql-hackers(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:
>
> > ohp(at)pyrenet(dot)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(at)pyrenet(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

ohp(at)pyrenet(dot)fr wrote:
> FWIW, I do confirm, on dual XEON with JT enabled

Operating system?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

ohp(at)pyrenet(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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-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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Larry Rosenman wrote:
>>
>>
>> --On Wednesday, September 03, 2003 16:51:51 -0400 Bruce Momjian
>> <pgman(at)candle(dot)pha(dot)pa(dot)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. 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?

$ 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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

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-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

Thanks.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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.3pthre
> >> ad. 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?
>
> $ 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Can you pass me what's in CVS (anon hasn't updated afaict).

And, what didn't you like about my version?

LER

--On Wednesday, September 03, 2003 18:35:44 -0400 Bruce Momjian
<pgman(at)candle(dot)pha(dot)pa(dot)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. 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?
>>
>> $ 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(at)lerctr(dot)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(at)candle(dot)pha(dot)pa(dot)us>
To: "Kurt Roeckx" <Q(at)ping(dot)be>
Cc: <pgsql-hackers(at)postgresql(dot)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-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
>
> Thanks.
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)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 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us) wrote:
>> 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.

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(at)candle(dot)pha(dot)pa(dot)us) wrote:
> >> 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.
>
> 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us> wrote:

> Jeroen Ruigrok/asmodai wrote:
>> -On [20030908 06:32], Bruce Momjian (pgman(at)candle(dot)pha(dot)pa(dot)us) wrote:
>> >> 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.
>>
>> 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(at)lerlaptop(dot)lerctr(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

-On [20030908 18:52], Bruce Momjian (pgman(at)candle(dot)pha(dot)pa(dot)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(at)gmx(dot)net

-On [20030908 23:52], Peter Eisentraut (peter_e(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:
> Manfred Spraul wrote:
> > Jeroen Ruigrok/asmodai wrote:
> >
> > >-On [20030908 23:52], Peter Eisentraut (peter_e(at)gmx(dot)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(at)candle(dot)pha(dot)pa(dot)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-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."
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, 10 Sep 2003 11:46 am, Bruce Momjian wrote:
> I see --- looks bad ---- failures below for OSF, Solaris, and FreeBSD
> below.

Actually, I am not sure the OSF failure is correctly reported... your test app
had me a little baffled in that case.

> We would have to get some thread mutex, make 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote:
> --- anyway, it is probably threadsafe, but strerror isn't, so we are
> dead anyway. :-)

Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when
everything else is... maybe Strange is OSF's middle name.

> > #ifdef SOME_DEF (sorry, 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.

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.