Thread: Thread configure flag
This applied patch adds --with-threads to configure. This will soon be hooked into libpq. Doc additions made too. -- 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 =================================================================== RCS file: /cvsroot/pgsql-server/configure,v retrieving revision 1.269 diff -c -c -r1.269 configure *** configure 12 Jun 2003 16:05:09 -0000 1.269 --- configure 13 Jun 2003 23:04:32 -0000 *************** *** 855,860 **** --- 855,861 ---- --with-libraries=DIRS look for additional libraries in DIRS --with-libs=DIRS alternative spelling of --with-libraries --with-pgport=PORTNUM change default port number 5432 + --with-threads allow libpq to be thread-safe --with-tcl build Tcl and Tk interfaces --without-tk do not build Tk interfaces if Tcl is enabled --with-tclconfig=DIR tclConfig.sh and tkConfig.sh are in DIR *************** *** 2810,2815 **** --- 2811,2851 ---- IFS=$ac_save_IFS # + # Enable libpq to be thread-safe + # + echo "$as_me:$LINENO: checking allow threaded libpq" >&5 + echo $ECHO_N "checking allow threaded libpq... $ECHO_C" >&6 + + + + # Check whether --with-threads or --without-threads was given. + if test "${with_threads+set}" = set; then + withval="$with_threads" + + case $withval in + yes) + : + ;; + no) + : + ;; + *) + { { echo "$as_me:$LINENO: error: no argument expected for --with-threads option" >&5 + echo "$as_me: error: no argument expected for --with-threads option" >&2;} + { (exit 1); exit 1; }; } + ;; + esac + + else + with_threads=no + + fi; + + echo "$as_me:$LINENO: result: $with_threads" >&5 + echo "${ECHO_T}$with_threads" >&6 + + + # # Tcl/Tk # echo "$as_me:$LINENO: checking whether to build with Tcl" >&5 *************** *** 3550,3556 **** # # Pthreads # ! echo "$as_me:$LINENO: checking for ANSI C header files" >&5 echo $ECHO_N "checking for ANSI C header files... $ECHO_C" >&6 if test "${ac_cv_header_stdc+set}" = set; then --- 3586,3592 ---- # # Pthreads # ! if test "$with_threads" = yes; then echo "$as_me:$LINENO: checking for ANSI C header files" >&5 echo $ECHO_N "checking for ANSI C header files... $ECHO_C" >&6 if test "${ac_cv_header_stdc+set}" = set; then *************** *** 3850,3874 **** fi if test $ac_cv_header_pthread_h = yes; then ! ! cat >>confdefs.h <<\_ACEOF ! #define HAVE_THREADS 1 ! _ACEOF ! fi ! if test ! -z "$HAVE_THREADS" ! then ! case $host_os in ! # BSD/OS and NetBSD require no special libraries or flags ! netbsd*|bsdi*) ;; freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS="-pthread" ;; freebsd*) THREAD_LIBS="-lc_r" ;; linux*) THREAD_LIBS="-lpthread" THREAD_CFLAGS="-D_REENTRANT" ;; ! # other operating systems might fail because they have pthread.h but need ! # special libs we don't know about yet. esac fi --- 3886,3923 ---- fi if test $ac_cv_header_pthread_h = yes; then ! : ! else ! { { echo "$as_me:$LINENO: error: pthread.h not found, required for --with-threads" >&5 ! echo "$as_me: error: pthread.h not found, required for --with-threads" >&2;} ! { (exit 1); exit 1; }; } fi ! case $host_os in ! netbsd*|bsdi*) ! # these require no special flags or libraries ! ;; freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS="-pthread" ;; freebsd*) THREAD_LIBS="-lc_r" ;; linux*) THREAD_LIBS="-lpthread" THREAD_CFLAGS="-D_REENTRANT" ;; ! *) ! # other operating systems might fail because they have pthread.h but need ! # special libs we don't know about yet. ! { { echo "$as_me:$LINENO: error: ! Cannot enable threads on your platform. ! Please report your platform threading info to the PostgreSQL mailing lists ! so it can be added to the next release. Report any compile or link flags, ! or libraries required for threading support. ! " >&5 ! echo "$as_me: error: ! Cannot enable threads on your platform. ! Please report your platform threading info to the PostgreSQL mailing lists ! so it can be added to the next release. Report any compile or link flags, ! or libraries required for threading support. ! " >&2;} ! { (exit 1); exit 1; }; } esac fi *************** *** 17540,17545 **** --- 17589,17595 ---- s,@GCC@,$GCC,;t t s,@autodepend@,$autodepend,;t t s,@INCLUDES@,$INCLUDES,;t t + s,@with_threads@,$with_threads,;t t s,@with_tcl@,$with_tcl,;t t s,@with_tk@,$with_tk,;t t s,@with_perl@,$with_perl,;t t Index: configure.in =================================================================== RCS file: /cvsroot/pgsql-server/configure.in,v retrieving revision 1.260 diff -c -c -r1.260 configure.in *** configure.in 12 Jun 2003 16:05:09 -0000 1.260 --- configure.in 13 Jun 2003 23:04:34 -0000 *************** *** 320,325 **** --- 320,333 ---- IFS=$ac_save_IFS # + # Enable libpq to be thread-safe + # + AC_MSG_CHECKING([allow threaded libpq]) + PGAC_ARG_BOOL(with, threads, no, [ --with-threads allow libpq to be thread-safe]) + AC_MSG_RESULT([$with_threads]) + AC_SUBST(with_threads) + + # # Tcl/Tk # AC_MSG_CHECKING([whether to build with Tcl]) *************** *** 544,563 **** # # Pthreads # ! ! AC_CHECK_HEADER(pthread.h, ! [AC_DEFINE(HAVE_THREADS, 1, [Define to 1 if you have the threads interface.])]) ! if test ! -z "$HAVE_THREADS" ! then ! case $host_os in ! # BSD/OS and NetBSD require no special libraries or flags ! netbsd*|bsdi*) ;; freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS="-pthread" ;; freebsd*) THREAD_LIBS="-lc_r" ;; linux*) THREAD_LIBS="-lpthread" THREAD_CFLAGS="-D_REENTRANT" ;; ! # other operating systems might fail because they have pthread.h but need ! # special libs we don't know about yet. esac fi AC_SUBST(THREAD_LIBS) --- 552,576 ---- # # Pthreads # ! if test "$with_threads" = yes; then ! AC_CHECK_HEADER(pthread.h, [], [AC_MSG_ERROR([pthread.h not found, required for --with-threads])]) ! case $host_os in ! netbsd*|bsdi*) ! # these require no special flags or libraries ! ;; freebsd2*|freebsd3*|freebsd4*) THREAD_CFLAGS="-pthread" ;; freebsd*) THREAD_LIBS="-lc_r" ;; linux*) THREAD_LIBS="-lpthread" THREAD_CFLAGS="-D_REENTRANT" ;; ! *) ! # other operating systems might fail because they have pthread.h but need ! # special libs we don't know about yet. ! AC_MSG_ERROR([ ! Cannot enable threads on your platform. ! Please report your platform threading info to the PostgreSQL mailing lists ! so it can be added to the next release. Report any compile or link flags, ! or libraries required for threading support. ! ]) esac fi AC_SUBST(THREAD_LIBS) Index: doc/src/sgml/installation.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/installation.sgml,v retrieving revision 1.133 diff -c -c -r1.133 installation.sgml *** doc/src/sgml/installation.sgml 11 Jun 2003 06:56:06 -0000 1.133 --- doc/src/sgml/installation.sgml 13 Jun 2003 23:04:36 -0000 *************** *** 915,920 **** --- 915,929 ---- </varlistentry> <varlistentry> + <term><option>--with-threads</option></term> + <listitem> + <para> + Allow separate libpq threads to safely control their private connection handles. + </para> + </listitem> + </varlistentry> + + <varlistentry> <term><option>--without-zlib</option></term> <listitem> <para> Index: doc/src/sgml/libpq.sgml =================================================================== RCS file: /cvsroot/pgsql-server/doc/src/sgml/libpq.sgml,v retrieving revision 1.123 diff -c -c -r1.123 libpq.sgml *** doc/src/sgml/libpq.sgml 14 May 2003 03:25:58 -0000 1.123 --- doc/src/sgml/libpq.sgml 13 Jun 2003 23:04:39 -0000 *************** *** 509,519 **** is leaked for each call to <function>PQconndefaults</function>. </para> - <para> - In <productname>PostgreSQL</productname> versions before 7.0, <function>PQconndefaults</function> returned a pointer - to a static array, rather than a dynamically allocated array. That - was not thread-safe, so the behavior has been changed. - </para> </listitem> </varlistentry> --- 509,514 ---- *************** *** 2549,2565 **** </indexterm> <para> ! <application>libpq</application> is thread-safe as of ! <productname>PostgreSQL</productname> 7.0, so long as no two threads ! attempt to manipulate the same <structname>PGconn</> object at the same ! time. In particular, you cannot issue concurrent commands from different ! threads through the same connection object. (If you need to run ! concurrent commands, start up multiple connections.) </para> <para> ! <structname>PGresult</> objects are read-only after creation, and so can be passed around ! freely between threads. </para> <para> --- 2544,2566 ---- </indexterm> <para> ! <application>libpq</application> is thread-safe if the library is ! compiled using the <literal>--with-threads</> ! <filename>configure</filename> command-line option. (You might need to ! use other threading command-line options to compile your client code.) ! </para> ! ! <para> ! One restriction is that no two threads attempt to manipulate the same ! <structname>PGconn</> object at the same time. In particular, you cannot ! issue concurrent commands from different threads through the same ! connection object. (If you need to run concurrent commands, start up ! multiple connections.) </para> <para> ! <structname>PGresult</> objects are read-only after creation, and so can be ! passed around freely between threads. </para> <para> Index: src/include/pg_config.h.in =================================================================== RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.in,v retrieving revision 1.50 diff -c -c -r1.50 pg_config.h.in *** src/include/pg_config.h.in 12 Jun 2003 07:36:51 -0000 1.50 --- src/include/pg_config.h.in 13 Jun 2003 23:04:41 -0000 *************** *** 468,476 **** /* Define to 1 if you have the <termios.h> header file. */ #undef HAVE_TERMIOS_H - /* Define to 1 if you have the threads interface. */ - #undef HAVE_THREADS - /* Define to 1 if your `struct tm' has `tm_zone'. Deprecated, use `HAVE_STRUCT_TM_TM_ZONE' instead. */ #undef HAVE_TM_ZONE --- 468,473 ----
Bruce Momjian writes: > This applied patch adds --with-threads to configure. This will soon be > hooked into libpq. Doc additions made too. Is there a reason why this isn't the default? -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > This applied patch adds --with-threads to configure. This will soon be > > hooked into libpq. Doc additions made too. > > Is there a reason why this isn't the default? > If it is the default, libpq is going to use the libc_r library, at least on some platforms, and that may not be desired. Fortunately, the flag has no effect on the backend code. One funny thing is that on BSD/OS and NetBSD, because there are no thread compile flags, function names, or libraries, libpq is the same code with or without the flag. ecpg, however, has thread calls, and is effected on every platform. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> This applied patch adds --with-threads to configure. This will soon be
>> hooked into libpq. Doc additions made too.
> Is there a reason why this isn't the default?
When Bruce and I discussed this last week, we assumed you'd object if
we did not do it this way ;-). --with-threads is a feature that can't
be supported on some platforms. Usually you argue that configure
shouldn't auto-enable features in some places and not others.
regards, tom lane
Tom Lane writes: > When Bruce and I discussed this last week, we assumed you'd object if > we did not do it this way ;-). --with-threads is a feature that can't > be supported on some platforms. Usually you argue that configure > shouldn't auto-enable features in some places and not others. But this isn't the same thing as supporting some external package. If readline is missing, you install it and repeat. But if thread-safeness is missing, there's nothing you can do. Therefore I think that the default behavior should be to do as good as the operating system can. Consider this: If an operating system did not support thread-safe applications outright (do such operating systems exist?) then users would never get the idea to write thread-safe libpq applications, so the option to make a thread-safe libpq would be useless. -- Peter Eisentraut peter_e@gmx.net
Bruce Momjian writes: > If it is the default, libpq is going to use the libc_r library, at least > on some platforms, and that may not be desired. But what is the objective reason for this lack of desire? > One funny thing is that on BSD/OS and NetBSD, because there are no > thread compile flags, function names, or libraries, libpq is the same > code with or without the flag. ecpg, however, has thread calls, and is > effected on every platform. Well, I'm pretty sure that the current thread options are overkill and can be simplified. For instance, on Linux the template currently claims THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS" _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the effect of _THREAD_SAFE is to define _REENTRANT, and the effect of _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use. In other words, this can be removed. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > If it is the default, libpq is going to use the libc_r library, at least > > on some platforms, and that may not be desired. > > But what is the objective reason for this lack of desire? libc_r could behave differently than libc on some platforms --- this is the reason we don't use some semaphore stuff in pthreads in backend code --- we don't know the ramifications. Also, --with-threads adds threading calls to ecpg, which I am not sure everyone would want in the default case. > > One funny thing is that on BSD/OS and NetBSD, because there are no > > thread compile flags, function names, or libraries, libpq is the same > > code with or without the flag. ecpg, however, has thread calls, and is > > effected on every platform. > > Well, I'm pretty sure that the current thread options are overkill and can > be simplified. For instance, on Linux the template currently claims No question. I just grabbed all the flags suggested. Many OS's are going to require such tweeking. > THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS" > > _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the > effect of _THREAD_SAFE is to define _REENTRANT, and the effect of > _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use. > In other words, this can be removed. You mean none of them are needed? Why would _REENTRANT only control getlogin_r()? Are all the other functions thread-safe already? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> If it is the default, libpq is going to use the libc_r library, at least
>> on some platforms, and that may not be desired.
> But what is the objective reason for this lack of desire?
I have heard that the reentrant libc is significantly worse-performing
than the non-reentrant one on some platforms. This is not real hard
to believe, since functions as common as malloc() will need locking
overhead if they think they might be in a multithreaded environment.
However, that's only an argument that we must provide a
--without-threads option, it doesn't speak strongly to the question of
what the default choice should be (where there is a choice).
> _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the
> effect of _THREAD_SAFE is to define _REENTRANT, and the effect of
> _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use.
On which version of Linux are the above statements true? Are you sure
they are true on other versions?
regards, tom lane
Tom Lane writes:
> I have heard that the reentrant libc is significantly worse-performing
> than the non-reentrant one on some platforms. This is not real hard
> to believe, since functions as common as malloc() will need locking
> overhead if they think they might be in a multithreaded environment.
Then maybe we should make a libpq and a libpq_r, etc. Then users have the
choice when they build their applications, and don't already have to think
about what their applications may require when building PostgreSQL.
(There is a libmysqlclient and a libmysqlclient_r, FWIW.)
> > _POSIX_PTHREAD_SEMANTICS isn't used anywhere in the entire system, the
> > effect of _THREAD_SAFE is to define _REENTRANT, and the effect of
> > _REENTRANT is to declare getlogin_r(), which PostgreSQL sources don't use.
>
> On which version of Linux are the above statements true? Are you sure
> they are true on other versions?
The documentation tells:
- Macro: _REENTRANT
- Macro: _THREAD_SAFE
If you define one of these macros, reentrant versions of several
functions get declared.
However, no function is specifically documented to require these macros.
Also, according to the change log of glibc, this state has existed since
about 1996, just the set of xxx_r() functions that were covered by these
macros has changed now and then.
SUSv3 documents a number of xxx_r() functions, but it doesn't speak of
_REENTRANT or _THREAD_SAFE anywhere.
So what I'm looking for is some documentation that states that such and
such flags is required to get such and such effect.
--
Peter Eisentraut peter_e@gmx.net
--On Tuesday, June 17, 2003 20:02:00 +0200 Peter Eisentraut <peter_e@gmx.net> wrote: > Tom Lane writes: > > SUSv3 documents a number of xxx_r() functions, but it doesn't speak of > _REENTRANT or _THREAD_SAFE anywhere. > > So what I'm looking for is some documentation that states that such and > such flags is required to get such and such effect. On UnixWare, you NEED to use -Kthread or -Kpthread, to get a Threads version. There are a NUMBER of functions that get wrapped, etc when these flags are specified. They also call in libthread.so. The doc at http://www.lerctr.org:8458/ might prove useful as a real-life example of a threaded kernel. LER > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- 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
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I have heard that the reentrant libc is significantly worse-performing
>> than the non-reentrant one on some platforms. This is not real hard
>> to believe, since functions as common as malloc() will need locking
>> overhead if they think they might be in a multithreaded environment.
> Then maybe we should make a libpq and a libpq_r, etc.
That would be fine with me ... although it's only worth doing if the
platform has a libc and a libc_r. Shall we use the existence of libc_r
to drive this choice?
regards, tom lane
On 17 Jun 2003 at 14:14, Tom Lane wrote: > > Then maybe we should make a libpq and a libpq_r, etc. > > That would be fine with me ... although it's only worth doing if the > platform has a libc and a libc_r. Shall we use the existence of libc_r > to drive this choice? I agree with this. If libpq is linked against libc_r for threading and mutex functions etc. and postgresql is linked against libc, then things like dblink which uses both postgresql and libc run into problem of symbol conflict. I experienced this on freeBSD and work around was to switch to linuxthreads which is not really good. If there are two versions of libraries available, we should do both. But that adds to bloat for certain. Just a thought. Bye Shridhar -- Lie, n.: A very poor substitute for the truth, but the only one discovered to date.
Shridhar Daithankar wrote: > On 17 Jun 2003 at 14:14, Tom Lane wrote: > > > Then maybe we should make a libpq and a libpq_r, etc. > > > > That would be fine with me ... although it's only worth doing if the > > platform has a libc and a libc_r. Shall we use the existence of libc_r > > to drive this choice? > > I agree with this. If libpq is linked against libc_r for threading and mutex > functions etc. and postgresql is linked against libc, then things like dblink > which uses both postgresql and libc run into problem of symbol conflict. I > experienced this on freeBSD and work around was to switch to linuxthreads which > is not really good. > > If there are two versions of libraries available, we should do both. But that > adds to bloat for certain. There are a couple of issues here: First, ecpg has actual thead creation function calls, so I believe we will still need a --with-threads configure option, at least to control ecpg, unless we make threading some kind of ecpg runtime flag. Second, we have some platforms that generate threaded libpq without any special flags --- libc is threaded by default and no special compile flags are required. So, if we move in the libpq_r direction, we will have some platforms that don't have libpq_r because they don't need it, and others that don't have it because they don't support threading or we don't know how to do threading in our configure tests. This seems very confusing to me. I wonder if we should just keep the current setup for 7.4 and collect theading configure information, then revisit this for 7.5. In the current code, if they ask for threads, they succeed or fail. With an automatic setup, I am not sure how to communicate to the user whether they are thread-safe or not. I believe this comes back to Peter's idea that we don't do things automatically, and if they ask for something, we should fail if we can't do it. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian writes: > First, ecpg has actual thead creation function calls, so I believe we > will still need a --with-threads configure option, at least to control > ecpg, unless we make threading some kind of ecpg runtime flag. This is not an issue because it only affects the libecpg library. > So, if we move in the libpq_r direction, we will have some platforms > that don't have libpq_r because they don't need it, and others that > don't have it because they don't support threading or we don't know how > to do threading in our configure tests. This seems very confusing to > me. On a system with a separate libc_r, you *already* need special compiler flags to link thread-safe applications. So it is only consistent that libpq applications also need special flags. For example, a normal application is linked so: cc -o prog prog1.o prog2.o -lpq -lc (well, you don't write the -lc) and a thread-safe application is linked so: cc -o prog prog1.o prog2.o -lpq_r -lc_r > I wonder if we should just keep the current setup for 7.4 and > collect theading configure information, then revisit this for 7.5. Well, when the packagers wrap up 7.4 they're going to need to make a call. Either it's not going to be thread-safe, and the work was in vain, or it's thread-safe and the concerns about the supposed performance hits are not addressed. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote: > Bruce Momjian writes: > > > First, ecpg has actual thead creation function calls, so I believe we > > will still need a --with-threads configure option, at least to control > > ecpg, unless we make threading some kind of ecpg runtime flag. > > This is not an issue because it only affects the libecpg library. So we would just have a libecpg and a libecpg_r? OK. > > So, if we move in the libpq_r direction, we will have some platforms > > that don't have libpq_r because they don't need it, and others that > > don't have it because they don't support threading or we don't know how > > to do threading in our configure tests. This seems very confusing to > > me. > > On a system with a separate libc_r, you *already* need special compiler > flags to link thread-safe applications. So it is only consistent that > libpq applications also need special flags. For example, a normal > application is linked so: > > cc -o prog prog1.o prog2.o -lpq -lc > > (well, you don't write the -lc) and a thread-safe application is linked > so: > > cc -o prog prog1.o prog2.o -lpq_r -lc_r OK, I am now wondering if we should just create non-thread libpq by default, and create threaded libpq for non-libc_r platforms and libpq and libpq_r for libc_r platforms, and of course fail on platforms where we don't know how to do threading. How is that? > > I wonder if we should just keep the current setup for 7.4 and > > collect theading configure information, then revisit this for 7.5. > > Well, when the packagers wrap up 7.4 they're going to need to make a call. > Either it's not going to be thread-safe, and the work was in vain, or it's > thread-safe and the concerns about the supposed performance hits are not > addressed. Well, it will not be in vain because people can still compile their own builds. I am not sure if we support enough platforms to enable all this by default in 7.4, and it could cause confusion. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
--On Saturday, June 21, 2003 15:57:54 -0400 Bruce Momjian <pgman@candle.pha.pa.us> wrote: \ >> Well, when the packagers wrap up 7.4 they're going to need to make a >> call. Either it's not going to be thread-safe, and the work was in vain, >> or it's thread-safe and the concerns about the supposed performance hits >> are not addressed. > > Well, it will not be in vain because people can still compile their own > builds. I am not sure if we support enough platforms to enable all this > by default in 7.4, and it could cause confusion. Did anyone see my comments about -Kthread/-Kpthread on UnixWare? That throws another mix into it. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749