threads stuff/UnixWare
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
Has any other platform come up with a need to look for the real pthread_*
calls from libpq?
I would REALLY like us to support threaded programs in UnixWare, and would
like to NOT antagonize the community, but would like to have a direction
I can go to make this happen in 7.5 before we freeze.
Thanks,
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 Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?Has any other platform come up with a need to look for the real pthread_*
calls from libpq?I would REALLY like us to support threaded programs in UnixWare, and would
like to NOT antagonize the community, but would like to have a direction
I can go to make this happen in 7.5 before we freeze.
Perfect time to start talking about it, at least :)
Do you have a proposed patch to look at for doing this?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 12:57:10 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?Has any other platform come up with a need to look for the real pthread_*
calls from libpq?I would REALLY like us to support threaded programs in UnixWare, and
would like to NOT antagonize the community, but would like to have a
direction I can go to make this happen in 7.5 before we freeze.Perfect time to start talking about it, at least :)
Do you have a proposed patch to look at for doing this?
No, as I believe the way I want to do it was frowned upon.
I'd LIKE to be able to have PG wrappers for those functions, and
have the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT threaded.
If they ARE present, indirect to the real functions.
I am looking for direction before expending a lot of effort on it, if it
will ultimately be rejected.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?
In what way does the current thread stuff not work for you?
regards, tom lane
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
At the risk of getting my butt kicked again, is there any way we can
talk about how to deal with threads on UnixWare and the libpq stuff?In what way does the current thread stuff not work for you?
regards, tom lane
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
UX:ld: ERROR: Symbol referencing errors. No output written to initdb
gmake[3]: *** [initdb] Error 1
gmake[3]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin/initdb'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/ler/pg-dev/pgsql-server/src/bin'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/home/ler/pg-dev/pgsql-server/src'
gmake: *** [all] Error 2
$
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.
Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...
No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a compiler
option (-Kpthread), to cause libpthread to be linked in.
Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
or
2) dynamically determine if libpthread is loaded and use the real pthread_*
functions if they are there (libpthread is in the image), or use fake
singlethread versions of the pthread_* calls if libpthread is NOT in the
image.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.so
Hmm. And that means what? Does Unixware not have these functions?
Are we just failing to suck in the needed library?
regards, tom lane
--On Wednesday, May 12, 2004 13:18:35 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 12:58:58 -0400 Tom Lane <tgl@sss.pgh.pa.us>
In what way does the current thread stuff not work for you?
In the initdb compile:
Undefined first referenced
symbol in file
pthread_mutex_unlock libpq.so
pthread_getspecific libpq.so
pthread_mutex_lock libpq.so
pthread_key_create libpq.so
pthread_once libpq.so
pthread_setspecific libpq.soHmm. And that means what? Does Unixware not have these functions?
Are we just failing to suck in the needed library?regards, tom lane
No, we don't pass the -Kpthread (thread CFLAGS) to the C links.
This is the whole discussion we had back in January/February about forcing
-Kpthread for *ALL* libpq using programs, or dynamically determining
if the image already is linked -Kpthread, or not supporting threads
at all on UW.
#3 is unacceptable to me.
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 Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and if
they are NOT there, use fake functions that assume we are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as pthread_,
right? so make Unixware specific #defines that map x_ to pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a compiler
option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT
threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as
pthread_, right? so make Unixware specific #defines that map x_ to
pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and have
the first invocation of them look via dlsym() for the real ones, and
if they are NOT there, use fake functions that assume we are NOT
threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are expecting
thread functinos to be called x_, while Unixware defines them as
pthread_, right? so make Unixware specific #defines that map x_ to
pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with -Kpthread
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.
deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:39:34 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:02:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 14:14:30 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
I'd LIKE to be able to have PG wrappers for those functions, and
have the first invocation of them look via dlsym() for the real
ones, and if they are NOT there, use fake functions that assume we
are NOT threaded.Wouldn't it be easier to have a #define?
Correct me if I'm wrong here, but the problem is that we are
expecting thread functinos to be called x_, while Unixware defines
them as pthread_, right? so make Unixware specific #defines that
map x_ to pthread_ ...No, we are expecting them to have pthread_*.
On UnixWare, to get the pthread_* functions, you need to invoke a
compiler option (-Kpthread), to cause libpthread to be linked in.Since libpq.so now REQUIRES the function, we need to either:
1) force ANY program that uses libpq to be compiled/linked with
-KpthreadUmmm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...
Bruce didn't want to muck ip all the .c programs in the distribution to
do that.
As well as any users using libpq.
I'm all ears if the COMMUNITY wants to do it.
LER
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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 Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution then
making wrappers for the pthread_* functions just to accommodate one OS ...
I could see it if this was a wide-spread problem, but it doesn't appear to
be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.
I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
--On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:
On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution
then making wrappers for the pthread_* functions just to accommodate
one OS ... I could see it if this was a wide-spread problem, but it
doesn't appear to be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?
initdb, et al.
See these comments in src/template/unixware:
# Disabled because flags are required for all apps using libpq.
# Waiting to see if other platforms need this too. 2004-03-22
THREAD_SUPPORT=yes
# verified UnixWare 7.1.4 2004-03-18
STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes
$
I turned it back on to see if the new stuff had fixed it.
----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy
ICQ: 7615664
--
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:
This is the whole discussion we had back in January/February about forcing
-Kpthread for *ALL* libpq using programs, or dynamically determining
if the image already is linked -Kpthread, or not supporting threads
at all on UW.
Oh, that business :-(. AFAIR we did not much care for any of the
proposed alternatives. Have you thought of any new options?
At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
regards, tom lane
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
This is the whole discussion we had back in January/February about
forcing -Kpthread for *ALL* libpq using programs, or dynamically
determining if the image already is linked -Kpthread, or not supporting
threads at all on UW.Oh, that business :-(. AFAIR we did not much care for any of the
proposed alternatives. Have you thought of any new options?At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
If I did the work for the dlsym() stuff would you and the rest of core@
accept it?
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
On Wed, 12 May 2004, Larry Rosenman wrote:
--On Wednesday, May 12, 2004 15:59:19 -0300 "Marc G. Fournier"
<scrappy@postgresql.org> wrote:On Wed, 12 May 2004, Larry Rosenman wrote:
Ummm, shouldn't that be added to the port specific Makefile?
See my reply to Tom. It forces ALL libpq using programs to be
linked with -Kpthread, which was deemed unacceptable.deemed unacceptable by whom? Sounds to me alot simpler of a solution
then making wrappers for the pthread_* functions just to accommodate
one OS ... I could see it if this was a wide-spread problem, but it
doesn't appear to be ...Bruce didn't want to muck ip all the .c programs in the distribution to
do that.I'm confused now ... what .c programs would have to be mucked up if you
add -Kpthread to the Unixware specific Makefile?initdb, et al.
See these comments in src/template/unixware:
# Disabled because flags are required for all apps using libpq.
# Waiting to see if other platforms need this too. 2004-03-22
THREAD_SUPPORT=yes
# verified UnixWare 7.1.4 2004-03-18
STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes
$I turned it back on to see if the new stuff had fixed it.
k, I just looked at the template/unixware file myself, and it looks to me
like -Kpthread is already defined, and included as part of THREAD_CPPFLAGS
... is THREAD_CPPFLAGS not honor'd in all of the various Makefile's (ie.
initdb?) ...
Please correct me if I'm wrong here, but so far, the issue seems to be
that now that libpq uses pthread_* by default, Unixware requires -Kpthread
to be used when building all the various support programs that use libpq
... and -Kpthread is defined in template/unixware ... so I'm *really*
confused as to what is actually broken, except maybe the Makefile's
themselves ...
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane <tgl@sss.pgh.pa.us>=20
wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.
If I did the work for the dlsym() stuff would you and the rest of core@
accept it?
How invasive a change are we talking about? I'd be inclined to reject a
patch that makes libpq materially less readable ...
regards, tom lane
--On Wednesday, May 12, 2004 16:00:48 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:
Larry Rosenman <ler@lerctr.org> writes:
--On Wednesday, May 12, 2004 15:39:54 -0400 Tom Lane
<tgl@sss.pgh.pa.us>=20 wrote:At this point I'd settle for saying that --enable-thread-safety on
Unixware will generate a library that requires -Kpthread. This is
kinda grungy but it seems that any more-pleasant solution would
require a disproportionate amount of work.If I did the work for the dlsym() stuff would you and the rest of core@
accept it?How invasive a change are we talking about? I'd be inclined to reject a
patch that makes libpq materially less readable ...regards, tom lane
I was thinking of pq_pthread_* calls, and that function would
set a static flag for calling either the real pthread_* function
or a statically named version in libpgport.a that is a single thread
wrapper.
I know, this sucks, but, I don't see any other way, other than linking
*ALL* libpq-using programs (including initdb and friends) with -K pthread.
--
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
