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