Обсуждение: thread_test.c problems

[Sorry, I hit the wrong butt on and sent this earlier before I meant to]

When I try to run thread_test.c from the CVS tip, it hangs in an infinite
CPU loop on both linux (RedHat AS 3.0, gcc 3.2.3) and Mac OS X 10.3.3 (gcc
3.3).  I've also tried down to gcc 2.96 on Mac OS X.

If I compile it with -g instead of -O2 on linux, it runs to completion and
gives me:

Add this to your template/$port file:

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=no
GETHOSTBYNAME_THREADSAFE=no

On Mac OS X, it gives me:

Add this to your template/$port file:

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes

If I modify the two while loops

   while (errno2_set == 0)

   while (errno1_set == 0)

To execute a 'print' statement or a 'time(NULL)' instead of a null loop,
then it runs to completion with -O2.



If I run the 7.4.2 released version of thread_test.c, for both platforms I
get:

Add this to your template/$port file:

NEED_REENTRANT_FUNCS=yes

There seems to be two problems

  1. It would appear the compiler is optimizing the while loop to be an
infinite loop.  Other explanations?

  2. The answers both can't be right...  On OS X, the 7.4.2 version says
NEED_REENTRANT_FUNCS=yes, but with the tip version it says all are thread
safe.



On linux, the make run (putting 'time(NULL)' in the loop):

make
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -I../../../src/include -D_GNU_SOURCE   -c -o
thread_test.o thread_test.c -MMD
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -L../../../src/port
-Wl,-rpath,/wdisk/wrp/opensrc/as30/local/pgsql7.4.2/lib -lpthread
thread_test.o -lz -lcrypt -lresolv -lnsl -ldl -lm -lbsd  -lpgport -o
thread_test
[wrp@juniper thread]$ !.
./thread_test
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
defines to your template/$port file before compiling this program.

Add this to your template/$port file:

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=no
GETHOSTBYNAME_THREADSAFE=no

wespvp,

have you tried adding a volatile keyword to the

int volatile errno1_set = 0;
int volatile errno2_set = 0;

that should stop while-loop optimizing for cases where the variable is modified in a scope the compiler would be
ignorantof, and precludes compiler while-loop optimization.  That would then tell you if it was a while loop
optimizationproblem. 

As for me on RH 8.0

gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared
--enable-threads=posix--disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit 
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

sorry, they all run yes/no/no

On Sat, Apr 03, 2004 at 03:40:01PM -0600, wespvp@syntegra.com wrote:
> [Sorry, I hit the wrong butt on and sent this earlier before I meant to]
>
> When I try to run thread_test.c from the CVS tip, it hangs in an infinite
> CPU loop on both linux (RedHat AS 3.0, gcc 3.2.3) and Mac OS X 10.3.3 (gcc
> 3.3).  I've also tried down to gcc 2.96 on Mac OS X.
>
> If I compile it with -g instead of -O2 on linux, it runs to completion and
> gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
> On Mac OS X, it gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=yes
>
> If I modify the two while loops
>
>    while (errno2_set == 0)
>
>    while (errno1_set == 0)
>
> To execute a 'print' statement or a 'time(NULL)' instead of a null loop,
> then it runs to completion with -O2.
>
>
>
> If I run the 7.4.2 released version of thread_test.c, for both platforms I
> get:
>
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=yes
>
> There seems to be two problems
>
>   1. It would appear the compiler is optimizing the while loop to be an
> infinite loop.  Other explanations?
>
>   2. The answers both can't be right...  On OS X, the 7.4.2 version says
> NEED_REENTRANT_FUNCS=yes, but with the tip version it says all are thread
> safe.
>
>
>
> On linux, the make run (putting 'time(NULL)' in the loop):
>
> make
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -I../../../src/include -D_GNU_SOURCE   -c -o
> thread_test.o thread_test.c -MMD
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -L../../../src/port
> -Wl,-rpath,/wdisk/wrp/opensrc/as30/local/pgsql7.4.2/lib -lpthread
> thread_test.o -lz -lcrypt -lresolv -lnsl -ldl -lm -lbsd  -lpgport -o
> thread_test
> [wrp@juniper thread]$ !.
> ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

--
joe speigle
www.sirfsup.com

On 4/4/04 12:33 AM, "joseph speigle" <joe.speigle@jklh.us> wrote:

> have you tried adding a volatile keyword to the
>
> int volatile errno1_set = 0;
> int volatile errno2_set = 0;
>
> that should stop while-loop optimizing for cases where the variable is
> modified in a scope the compiler would be ignorant of, and precludes compiler
> while-loop optimization.  That would then tell you if it was a while loop
> optimization problem.

That cures the problem on all systems.  What needs to be done to get this
updated in the tip?

> As for me on RH 8.0
>
> gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --disable-checking --host=i386-redhat-linux --with-system-zlib
> --enable-__cxa_atexit
> Thread model: posix
> gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
>
> sorry, they all run yes/no/no

I don't know what is different, but I've tried it on RH 7.2, RH AS 3.0, and
Mac OS X.  All hang in an infinite loop with the tip version of
thread_test.c, and all work if I add 'volatile' to the definitions of
errno1_set and errno2_set.

There's still the question of which version of the program is giving the
right answers - the 7.4.2 version or the tip version?


RH 7.2:

[wrp@cherry thread]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)


RH AS 3.0:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24)


Mac OS X:

% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1495)



Wes

wespvp@syntegra.com wrote:
> On 4/4/04 12:33 AM, "joseph speigle" <joe.speigle@jklh.us> wrote:
>
> > have you tried adding a volatile keyword to the
> >
> > int volatile errno1_set = 0;
> > int volatile errno2_set = 0;
> >
> > that should stop while-loop optimizing for cases where the variable is
> > modified in a scope the compiler would be ignorant of, and precludes compiler
> > while-loop optimization.  That would then tell you if it was a while loop
> > optimization problem.
>
> That cures the problem on all systems.  What needs to be done to get this
> updated in the tip?
>
> > As for me on RH 8.0
> >
> > gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
> > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> > --infodir=/usr/share/info --enable-shared --enable-threads=posix
> > --disable-checking --host=i386-redhat-linux --with-system-zlib
> > --enable-__cxa_atexit
> > Thread model: posix
> > gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
> >
> > sorry, they all run yes/no/no
>
> I don't know what is different, but I've tried it on RH 7.2, RH AS 3.0, and
> Mac OS X.  All hang in an infinite loop with the tip version of
> thread_test.c, and all work if I add 'volatile' to the definitions of
> errno1_set and errno2_set.
>
> There's still the question of which version of the program is giving the
> right answers - the 7.4.2 version or the tip version?

I have applied the following patch to CVS head which does a getpid() in
the loop, rather than nothing.  getpid() should force a system call,
which will make it more likely for the other thread to get CPU time and
complete its tests.

--
  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: thread_test.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -c -c -r1.9 -r1.10
*** thread_test.c    28 Mar 2004 02:37:31 -0000    1.9
--- thread_test.c    4 Apr 2004 17:23:54 -0000    1.10
***************
*** 105,111 ****
      /* wait for other thread to set errno */
      errno1_set = 1;
      while (errno2_set == 0)
!         /* loop */;
      if (errno != EEXIST)
      {
              fprintf(stderr, "errno not thread-safe; exiting\n");
--- 105,111 ----
      /* wait for other thread to set errno */
      errno1_set = 1;
      while (errno2_set == 0)
!         getpid();    /* force system call */
      if (errno != EEXIST)
      {
              fprintf(stderr, "errno not thread-safe; exiting\n");
***************
*** 128,135 ****
          passwd_p1 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p1 = gethostbyname("yahoo.com");
!     p = gethostbyname("slashdot.org");
      if (hostent_p1 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
--- 128,135 ----
          passwd_p1 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p1 = gethostbyname("www.yahoo.com");
!     p = gethostbyname("www.weather.com");
      if (hostent_p1 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
***************
*** 151,157 ****
      /* wait for other thread to set errno */
      errno2_set = 1;
      while (errno1_set == 0)
!         /* loop */;
      if (errno != ENOENT)
      {
              fprintf(stderr, "errno not thread-safe; exiting\n");
--- 151,157 ----
      /* wait for other thread to set errno */
      errno2_set = 1;
      while (errno1_set == 0)
!         getpid();    /* force system call */
      if (errno != ENOENT)
      {
              fprintf(stderr, "errno not thread-safe; exiting\n");
***************
*** 174,181 ****
          passwd_p2 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p2 = gethostbyname("google.com");
!     p = gethostbyname("postgresql.org");
      if (hostent_p2 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
--- 174,181 ----
          passwd_p2 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p2 = gethostbyname("www.google.com");
!     p = gethostbyname("www.postgresql.org");
      if (hostent_p2 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");

> I have applied the following patch to CVS head which does a getpid() in
> the loop, rather than nothing.  getpid() should force a system call,
> which will make it more likely for the other thread to get CPU time and
> complete its tests.

Works for me...

However, there seems to be a reliability problem with the results:


[g4:src/tools/thread] wp% ./thread_test
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
defines to your template/$port file before compiling this program.

Add this to your template/$port file:

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=no

[g4:src/tools/thread] wp% ./thread_test
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
defines to your template/$port file before compiling this program.

Add this to your template/$port file:

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes


It returns mostly 'yes' for all three, but sometimes returns 'no' for the
last one.  I get the same conflicting results whether I run with one or two
CPU's enabled.

Similarly, the 7.4.2 release is showing:

% ./thread_test
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
defines to your template/$port file before compiling this program.

All your non-*_r functions are thread-safe.
Add this to your template/$port file:

NEED_REENTRANT_FUNCS=no


% ./thread_test
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
defines to your template/$port file before compiling this program.

Your gethostbyname() is _not_ thread-safe
Not all non-*_r functions are thread-safe.
Add this to your template/$port file:

NEED_REENTRANT_FUNCS=yes



I assume the safe bet is GETHOSTBYNAME_THREADSAFE=no for the tip and
NEED_REENTRANT_FUNCS=yes for 7.4.2?  Can I rely on the other two being
'yes', or should they be set to 'no' also?

Based on the linux template and the output of thread_test, I have set up the
darwin template and compiled the CVS tip code on Mac OS X 10.3.3 with:



# Apple's cpp-precomp seems a tad broken, so don't use it
# (Note: on OS X before 10.2, you might need -traditional-cpp instead)
#CC="$CC -no-cpp-precomp"

# Select appropriate semaphore support
USE_NAMED_POSIX_SEMAPHORES=1

# tools/thread/thread_test must be run
THREAD_SUPPORT=yes
THREAD_CPPFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-lpthread"

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=no

#NEED_REENTRANT_FUNCS=yes




I commented out the 'CC="$CC -no-cpp-precomp"' line and did not get any
compile errors.  Mac OS X 10.3.3 uses GCC 3.3.  I know something changed
between Mac OS X 10.2 and 10.3 regarding precomp (they also upgraded from
gcc 2.96 to 3.3).  It seems to compile ok on 10.3 regardless of the setting
of this parameter, so unless it is important to have it enabled when
possible, it is probably best to leave it off for backwards compatibility?

I also added all of the thread lines starting with the comment '#
tools/thread/thread_test must be run' based on the output of thread_test.
The released PostgreSQL 7.4.2 says I should use 'NEED_REENTRANT_FUNCS=yes'.

Wes

wespvp@syntegra.com wrote:
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=no
>
> [g4:src/tools/thread] wp% ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=yes
>
>
> It returns mostly 'yes' for all three, but sometimes returns 'no' for the
> last one.  I get the same conflicting results whether I run with one or two
> CPU's enabled.
>

OK, I know the cause of this.  The problem is that sometimes hostnames
don't resolve, and the bigger problem is that it requires an internet
connection to run the tests.  The attached patch tests for 'localhost'
and your local hostname, so it should work reliably.


> Similarly, the 7.4.2 release is showing:
>
> % ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> All your non-*_r functions are thread-safe.
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=no
>
>
> % ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Your gethostbyname() is _not_ thread-safe
> Not all non-*_r functions are thread-safe.
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=yes
>
>
>
> I assume the safe bet is GETHOSTBYNAME_THREADSAFE=no for the tip and
> NEED_REENTRANT_FUNCS=yes for 7.4.2?  Can I rely on the other two being
> 'yes', or should they be set to 'no' also?

Yes, that is the safe bet on 7.4.X.  7.5 will use individual entries for
each function, and in fact we might have this all merged into configure
by then anyway.


>
> Based on the linux template and the output of thread_test, I have set up the
> darwin template and compiled the CVS tip code on Mac OS X 10.3.3 with:
>
>
>
> # Apple's cpp-precomp seems a tad broken, so don't use it
> # (Note: on OS X before 10.2, you might need -traditional-cpp instead)
> #CC="$CC -no-cpp-precomp"
>
> # Select appropriate semaphore support
> USE_NAMED_POSIX_SEMAPHORES=1
>
> # tools/thread/thread_test must be run
> THREAD_SUPPORT=yes
> THREAD_CPPFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
> THREAD_LIBS="-lpthread"
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=no
>
> #NEED_REENTRANT_FUNCS=yes
>
>
>
>
> I commented out the 'CC="$CC -no-cpp-precomp"' line and did not get any
> compile errors.  Mac OS X 10.3.3 uses GCC 3.3.  I know something changed
> between Mac OS X 10.2 and 10.3 regarding precomp (they also upgraded from
> gcc 2.96 to 3.3).  It seems to compile ok on 10.3 regardless of the setting
> of this parameter, so unless it is important to have it enabled when
> possible, it is probably best to leave it off for backwards compatibility?
>
> I also added all of the thread lines starting with the comment '#
> tools/thread/thread_test must be run' based on the output of thread_test.
> The released PostgreSQL 7.4.2 says I should use 'NEED_REENTRANT_FUNCS=yes'.

Yes, in 7.4.X, you only need that single entry.

Thanks for the testing.

--
  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: src/tools/thread/thread_test.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.10
diff -c -c -r1.10 thread_test.c
*** src/tools/thread/thread_test.c    4 Apr 2004 17:23:54 -0000    1.10
--- src/tools/thread/thread_test.c    5 Apr 2004 01:22:04 -0000
***************
*** 35,40 ****
--- 35,42 ----
  void func_call_1(void);
  void func_call_2(void);

+ char myhostname[MAXHOSTNAMELEN];
+
  int errno1_set = 0;
  int errno2_set = 0;

***************
*** 61,66 ****
--- 63,74 ----
              return 1;
      }

+     if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
+     {
+             fprintf(stderr, "can not get local hostname, exiting\n");
+             exit(1);
+     }
+
      printf("\
  Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
  defines to your template/$port file before compiling this program.\n\n"
***************
*** 128,135 ****
          passwd_p1 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p1 = gethostbyname("www.yahoo.com");
!     p = gethostbyname("www.weather.com");
      if (hostent_p1 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
--- 136,144 ----
          passwd_p1 = NULL;    /* force thread-safe failure report */
      }

!     /* threads do this in opposite order */
!     hostent_p1 = gethostbyname(myhostname);
!     p = gethostbyname("localhost");
      if (hostent_p1 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
***************
*** 174,181 ****
          passwd_p2 = NULL;    /* force thread-safe failure report */
      }

!     hostent_p2 = gethostbyname("www.google.com");
!     p = gethostbyname("www.postgresql.org");
      if (hostent_p2 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");
--- 183,191 ----
          passwd_p2 = NULL;    /* force thread-safe failure report */
      }

!     /* threads do this in opposite order */
!     hostent_p2 = gethostbyname("localhost");
!     p = gethostbyname(myhostname);
      if (hostent_p2 != p)
      {
          printf("Your gethostbyname() changes the static memory area between calls\n");

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> wespvp@syntegra.com wrote:
> have you tried adding a volatile keyword to the
> int volatile errno1_set = 0;
> int volatile errno2_set = 0;
>
> I have applied the following patch to CVS head which does a getpid() in
> the loop, rather than nothing.

That does not cure the bug identified by wespvp.  It may make it a
little less likely that the compiler will choose to optimize out the
loop test, but only adding "volatile" really fixes the problem in
a language-standard-compliant way.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > wespvp@syntegra.com wrote:
> > have you tried adding a volatile keyword to the
> > int volatile errno1_set = 0;
> > int volatile errno2_set = 0;
> >
> > I have applied the following patch to CVS head which does a getpid() in
> > the loop, rather than nothing.
>
> That does not cure the bug identified by wespvp.  It may make it a
> little less likely that the compiler will choose to optimize out the
> loop test, but only adding "volatile" really fixes the problem in
> a language-standard-compliant way.

Thanks, 'volatile' added to the thread-specific errno variables:

    volatile int errno1_set = 0;
    volatile int errno2_set = 0;

--
  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 4/4/04 7:28 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> OK, I know the cause of this.  The problem is that sometimes hostnames
> don't resolve, and the bigger problem is that it requires an internet
> connection to run the tests.  The attached patch tests for 'localhost'
> and your local hostname, so it should work reliably.

I did a cvs update, make, then rebuilt and tested thread_test.  I ran it
about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the
time.  I got "GETHOSTBYNAME_THREADSAFE=no" three times.  The other two were
always "yes".

I did verify that both the "volatile" and "localhost" changes were in there.

Dumb question...  Why would you not always use the _r functions if they
exist?

Wes

wespvp@syntegra.com wrote:
> On 4/4/04 7:28 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > OK, I know the cause of this.  The problem is that sometimes hostnames
> > don't resolve, and the bigger problem is that it requires an internet
> > connection to run the tests.  The attached patch tests for 'localhost'
> > and your local hostname, so it should work reliably.
>
> I did a cvs update, make, then rebuilt and tested thread_test.  I ran it
> about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the
> time.  I got "GETHOSTBYNAME_THREADSAFE=no" three times.  The other two were
> always "yes".

Yep, I can reproduce this on BSD/OS too, so it must be something wrong
with my program.  I see:

    $ for X in `jot 1000`; do thread_test |grep -10 '=no' && echo $X;
      done|less
    Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
    defines to your template/$port file before compiling this program.

    Add this to your template/$port file:

    STRERROR_THREADSAFE=yes
    GETPWUID_THREADSAFE=no
    GETHOSTBYNAME_THREADSAFE=no
    919

I bet the problem is that I am accessing thread-specific pointers after
the thread exits.  It is possible thread 1 completes before thread2 gets
to the getpwuid and gethostbyname tests, and then reuses the
thread-specific pointer.  Let me work on a patch and email it to you in
a few minutes.

> I did verify that both the "volatile" and "localhost" changes were in there.
>
> Dumb question...  Why would you not always use the _r functions if they
> exist?

Yes, we do use *_r functions in 7.5 if they exist, but in 7.4.X, I think
we use the non-R if we can, though we actually just use getaddrinfo() in
7.4.X if it exists.  Basically, the threading tests are still in flux,
as you can see, in 7.4.X.  It works, but it isn't 100% configure perfect
yet.

--
  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 wrote:
> > I did a cvs update, make, then rebuilt and tested thread_test.  I ran it
> > about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the
> > time.  I got "GETHOSTBYNAME_THREADSAFE=no" three times.  The other two were
> > always "yes".
>
> Yep, I can reproduce this on BSD/OS too, so it must be something wrong
> with my program.  I see:
>
>     $ for X in `jot 1000`; do thread_test |grep -10 '=no' && echo $X;
>       done|less
>     Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
>     defines to your template/$port file before compiling this program.
>
>     Add this to your template/$port file:
>
>     STRERROR_THREADSAFE=yes
>     GETPWUID_THREADSAFE=no
>     GETHOSTBYNAME_THREADSAFE=no
>     919
>
> I bet the problem is that I am accessing thread-specific pointers after
> the thread exits.  It is possible thread 1 completes before thread2 gets
> to the getpwuid and gethostbyname tests, and then reuses the
> thread-specific pointer.  Let me work on a patch and email it to you in
> a few minutes.

OK, new patch applied that causes all threads to wait until the parent
checks their thread-specific pointers. I ran 1000 tests and all passed.
Hopefully it will good for you 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: src/tools/thread/thread_test.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.12
diff -c -c -r1.12 thread_test.c
*** src/tools/thread/thread_test.c    5 Apr 2004 02:22:14 -0000    1.12
--- src/tools/thread/thread_test.c    5 Apr 2004 05:40:13 -0000
***************
*** 40,45 ****
--- 40,48 ----
  volatile int errno1_set = 0;
  volatile int errno2_set = 0;

+ volatile int thread1_done = 0;
+ volatile int thread2_done = 0;
+
  char *strerror_p1;
  char *strerror_p2;

***************
*** 49,57 ****
  struct hostent *hostent_p1;
  struct hostent *hostent_p2;

! pthread_mutex_t singlethread_lock1 = PTHREAD_MUTEX_INITIALIZER;
! pthread_mutex_t singlethread_lock2 = PTHREAD_MUTEX_INITIALIZER;
!
  int main(int argc, char *argv[])
  {
      pthread_t        thread1,
--- 52,59 ----
  struct hostent *hostent_p1;
  struct hostent *hostent_p2;

! pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
!
  int main(int argc, char *argv[])
  {
      pthread_t        thread1,
***************
*** 73,82 ****
  Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
  defines to your template/$port file before compiling this program.\n\n"
  );
      pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
      pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);
!     pthread_join(thread1, NULL);
!     pthread_join(thread2, NULL);

      printf("Add this to your template/$port file:\n\n");

--- 75,89 ----
  Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
  defines to your template/$port file before compiling this program.\n\n"
  );
+
+     /* Hold lock until we are ready for the child threads to exit. */
+     pthread_mutex_lock(&init_mutex);
+
      pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
      pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);
!
!     while (thread1_done == 0 || thread2_done == 0)
!         getpid();    /* force system call */

      printf("Add this to your template/$port file:\n\n");

***************
*** 94,100 ****
--- 101,112 ----
          printf("GETHOSTBYNAME_THREADSAFE=yes\n");
      else
          printf("GETHOSTBYNAME_THREADSAFE=no\n");
+
+     pthread_mutex_unlock(&init_mutex);    /* let children exit  */

+     pthread_join(thread1, NULL);    /* clean up children */
+     pthread_join(thread2, NULL);
+
      return 0;
  }

***************
*** 110,116 ****
              fprintf(stderr, "could not generate failure for create file in /tmp, exiting\n");
              exit(1);
      }
!     /* wait for other thread to set errno */
      errno1_set = 1;
      while (errno2_set == 0)
          getpid();    /* force system call */
--- 122,132 ----
              fprintf(stderr, "could not generate failure for create file in /tmp, exiting\n");
              exit(1);
      }
!     /*
!      *    Wait for other thread to set errno.
!      *    We can't use thread-specific locking here because it might
!      *    affect errno.
!      */
      errno1_set = 1;
      while (errno2_set == 0)
          getpid();    /* force system call */
***************
*** 144,149 ****
--- 160,169 ----
          printf("Your gethostbyname() changes the static memory area between calls\n");
          hostent_p1 = NULL;    /* force thread-safe failure report */
      }
+
+     thread1_done = 1;
+     pthread_mutex_lock(&init_mutex);    /* wait for parent to test */
+     pthread_mutex_unlock(&init_mutex);
  }


***************
*** 157,163 ****
              fprintf(stderr, "Read-only open succeeded without create, exiting\n");
              exit(1);
      }
!     /* wait for other thread to set errno */
      errno2_set = 1;
      while (errno1_set == 0)
          getpid();    /* force system call */
--- 177,187 ----
              fprintf(stderr, "Read-only open succeeded without create, exiting\n");
              exit(1);
      }
!     /*
!      *    Wait for other thread to set errno.
!      *    We can't use thread-specific locking here because it might
!      *    affect errno.
!      */
      errno2_set = 1;
      while (errno1_set == 0)
          getpid();    /* force system call */
***************
*** 191,194 ****
--- 215,222 ----
          printf("Your gethostbyname() changes the static memory area between calls\n");
          hostent_p2 = NULL;    /* force thread-safe failure report */
      }
+
+     thread2_done = 1;
+     pthread_mutex_lock(&init_mutex);    /* wait for parent to test */
+     pthread_mutex_unlock(&init_mutex);
  }

On 4/4/04 11:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> OK, new patch applied that causes all threads to wait until the parent
> checks their thread-specific pointers. I ran 1000 tests and all passed.
> Hopefully it will good for you too.

I'll try to give it a test tonight.

>> Dumb question...  Why would you not always use the _r functions if they
>> exist?
>
> Yes, we do use *_r functions in 7.5 if they exist, but in 7.4.X, I think
> we use the non-R if we can, though we actually just use getaddrinfo() in
> 7.4.X if it exists.  Basically, the threading tests are still in flux,
> as you can see, in 7.4.X.  It works, but it isn't 100% configure perfect
> yet.

I'm still not clear on this...  The thread_test program checks to see if the
non-r functions are thread safe.  If so, it directs you to set xxxx=yes in
the template file - I assume that causes the non-r function to be used.  If
they are not thread safe, it directs you to use xxxx=no - which I assume
causes the *_r functions to be used.  Why would you not *always* use the _r
functions if they exist, and only check for thread safety if the _r
functions do not exist?

Or, am I misunderstanding how the xxx=yes is used?

Wes

wespvp@syntegra.com wrote:
> On 4/4/04 11:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > OK, new patch applied that causes all threads to wait until the parent
> > checks their thread-specific pointers. I ran 1000 tests and all passed.
> > Hopefully it will good for you too.
>
> I'll try to give it a test tonight.

Please grab CVS.  I added sched_yield() too.

>
> >> Dumb question...  Why would you not always use the _r functions if they
> >> exist?
> >
> > Yes, we do use *_r functions in 7.5 if they exist, but in 7.4.X, I think
> > we use the non-R if we can, though we actually just use getaddrinfo() in
> > 7.4.X if it exists.  Basically, the threading tests are still in flux,
> > as you can see, in 7.4.X.  It works, but it isn't 100% configure perfect
> > yet.
>
> I'm still not clear on this...  The thread_test program checks to see if the
> non-r functions are thread safe.  If so, it directs you to set xxxx=yes in
> the template file - I assume that causes the non-r function to be used.  If
> they are not thread safe, it directs you to use xxxx=no - which I assume
> causes the *_r functions to be used.  Why would you not *always* use the _r
> functions if they exist, and only check for thread safety if the _r
> functions do not exist?
>
> Or, am I misunderstanding how the xxx=yes is used?

In 7.4.X, the thought was that if the native function are already
thread-safe, why bother calling the *_r functions, but in 7.5, we
decided it was better to use the *_r functions --- again, 7.4.X has
threads working, but the configure issues were in flux as we learned how
each platform handled threading.

--
  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 <pgman@candle.pha.pa.us> writes:

> wespvp@syntegra.com wrote:
> > On 4/4/04 11:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
> >
> > > OK, new patch applied that causes all threads to wait until the parent
> > > checks their thread-specific pointers. I ran 1000 tests and all passed.
> > > Hopefully it will good for you too.
> >
> > I'll try to give it a test tonight.
>
> Please grab CVS.  I added sched_yield() too.

Make sure to test this on linux 2.6. They changed sched_yield() to not cause
context switches in a lot of cases where it did previously. You might need a
usleep() there instead or in addition.

--
greg

Greg Stark wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>
> > wespvp@syntegra.com wrote:
> > > On 4/4/04 11:43 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
> > >
> > > > OK, new patch applied that causes all threads to wait until the parent
> > > > checks their thread-specific pointers. I ran 1000 tests and all passed.
> > > > Hopefully it will good for you too.
> > >
> > > I'll try to give it a test tonight.
> >
> > Please grab CVS.  I added sched_yield() too.
>
> Make sure to test this on linux 2.6. They changed sched_yield() to not cause
> context switches in a lot of cases where it did previously. You might need a
> usleep() there instead or in addition.


Usleep is probably more unportable than sched_yield on platforms that
support threads.  I actually don't need sched_yield to context switch,
only to allow the other threads to complete.

--
  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 4/5/04 8:31 AM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

>>> OK, new patch applied that causes all threads to wait until the parent
>>> checks their thread-specific pointers. I ran 1000 tests and all passed.
>>> Hopefully it will good for you too.
>>
>> I'll try to give it a test tonight.
>
> Please grab CVS.  I added sched_yield() too.

Ok, I did a cvs update and reran the test.  It now consistently returns
'YES' to all three questions.  Thanks.

What needs to be done to get the standard Darwin template file updated to
enable threading?

Wes

wespvp@syntegra.com wrote:
> On 4/5/04 8:31 AM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> >>> OK, new patch applied that causes all threads to wait until the parent
> >>> checks their thread-specific pointers. I ran 1000 tests and all passed.
> >>> Hopefully it will good for you too.
> >>
> >> I'll try to give it a test tonight.
> >
> > Please grab CVS.  I added sched_yield() too.
>
> Ok, I did a cvs update and reran the test.  It now consistently returns
> 'YES' to all three questions.  Thanks.
>
> What needs to be done to get the standard Darwin template file updated to
> enable threading?

Oh, that is a problem because other linux's show 'no' for the last two.

My plan is to have 'configure' run this program as part of its
operation, and Jan has some thread configure scripts, and this will all
be automated in 7.5 so no one will have to run the program manually.

--
  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 <pgman@candle.pha.pa.us> writes:
> My plan is to have 'configure' run this program as part of its
> operation,

Peter's not going to be happy with you ;-)  Runtime configure tests are
not part of the Grand Plan --- ideally configure should only have to do
compile and link tests.

            regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > My plan is to have 'configure' run this program as part of its
> > operation,
>
> Peter's not going to be happy with you ;-)  Runtime configure tests are
> not part of the Grand Plan --- ideally configure should only have to do
> compile and link tests.

Yep, I am sure he isn't, but looking at platforms that have different
thread-safety capabilities, I can't see a way around it.  We could
argue that the thread test is testing the thread library, not the actual
computer it is running in.  For example, it isn't do a 'df'.

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

I have just commited to CVS code that will do all the compile/library
flags and thread tests automatically.   Let me know how it works for
you.  Thanks.

---------------------------------------------------------------------------

wespvp@syntegra.com wrote:
> On 4/5/04 8:31 AM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> >>> OK, new patch applied that causes all threads to wait until the parent
> >>> checks their thread-specific pointers. I ran 1000 tests and all passed.
> >>> Hopefully it will good for you too.
> >>
> >> I'll try to give it a test tonight.
> >
> > Please grab CVS.  I added sched_yield() too.
>
> Ok, I did a cvs update and reran the test.  It now consistently returns
> 'YES' to all three questions.  Thanks.
>
> What needs to be done to get the standard Darwin template file updated to
> enable threading?
>
> Wes
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

--
  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 4/23/04 6:59 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

>
> I have just commited to CVS code that will do all the compile/library
> flags and thread tests automatically.   Let me know how it works for
> you.  Thanks.

No, I don't think it is right.  I did a 'cvs update', then ran 'configure'.
Templates/darwin contains the information below.  I don't know if it is
supposed to contain the three *_TREADSAFE lines any more, but shouldn't it
at least have the 'THREAD_SUPPORT' and 'THREAD_LIBS' entries?

The output of thread_test run manually is:

wrp% ./thread_test
Your errno is thread-safe.
Your system has sterror_r();  it does not need strerror().
Your system has getpwuid_r();  it does not need getpwuid().
Your system has getaddrinfo();  it does not need gethostbyname()
  or gethostbyname_r().

Your platform is thread-safe.


------
The current darwin file:
------

# Apple's cpp-precomp seems a tad broken, so don't use it
# (Note: on OS X before 10.2, you might need -traditional-cpp instead)
CC="$CC -no-cpp-precomp"

# Select appropriate semaphore support
USE_NAMED_POSIX_SEMAPHORES=1

# verified Mac OS X 10.3.3, Darwin Kernel Version 7.3.0, 2004-04-07
PTHREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"

-------
The darwin file I had been using with 10.3.3 is:
-------


# Apple's cpp-precomp seems a tad broken, so don't use it
# (Note: on OS X before 10.2, you might need -traditional-cpp instead)
#CC="$CC -no-cpp-precomp"

# Select appropriate semaphore support
USE_NAMED_POSIX_SEMAPHORES=1

# tools/thread/thread_test must be run
THREAD_SUPPORT=yes
THREAD_CPPFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
THREAD_LIBS="-lpthread"

STRERROR_THREADSAFE=yes
GETPWUID_THREADSAFE=yes
GETHOSTBYNAME_THREADSAFE=yes

#NEED_REENTRANT_FUNCS=yes

wespvp@syntegra.com wrote:
> On 4/23/04 6:59 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> >
> > I have just commited to CVS code that will do all the compile/library
> > flags and thread tests automatically.   Let me know how it works for
> > you.  Thanks.
>
> No, I don't think it is right.  I did a 'cvs update', then ran 'configure'.
> Templates/darwin contains the information below.  I don't know if it is
> supposed to contain the three *_TREADSAFE lines any more, but shouldn't it
> at least have the 'THREAD_SUPPORT' and 'THREAD_LIBS' entries?

No, see pgsql/config/acx_pthread.m4.  It does the THREAD_LIBS part
automatically, and the THREAD_SUPPORT part is gone.  We run our thread
test as part of configure now.


--
  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 4/24/04 9:15 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> No, see pgsql/config/acx_pthread.m4.  It does the THREAD_LIBS part
> automatically, and the THREAD_SUPPORT part is gone.  We run our thread
> test as part of configure now.

I must be missing something.  I don't see a -lpthread anywhere.  The libpq
linking is:

gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations  -bundle fe-auth.o fe-connect.o fe-exec.o fe-misc.o
fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o
fe-secure.o dllist.o md5.o ip.o wchar.o encnames.o noblock.o path.o thread.o
-L../../../src/port -lssl -lcrypto -lkrb5 -lresolv -D_REENTRANT
-D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS   -o libpq.so.3.2

How can this be linking in thread support without -lpthread?

Wes

wespvp@syntegra.com wrote:
> On 4/24/04 9:15 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > No, see pgsql/config/acx_pthread.m4.  It does the THREAD_LIBS part
> > automatically, and the THREAD_SUPPORT part is gone.  We run our thread
> > test as part of configure now.
>
> I must be missing something.  I don't see a -lpthread anywhere.  The libpq
> linking is:
>
> gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations  -bundle fe-auth.o fe-connect.o fe-exec.o fe-misc.o
> fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o
> fe-secure.o dllist.o md5.o ip.o wchar.o encnames.o noblock.o path.o thread.o
> -L../../../src/port -lssl -lcrypto -lkrb5 -lresolv -D_REENTRANT
> -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS   -o libpq.so.3.2
>
> How can this be linking in thread support without -lpthread?

In config/acx_pthreasd.m4, I see:

    acx_pthread_flags="pthreads none -Kthread -kthread lthread \
    -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-conf
    ...

The configure test should be trying -lpthread as part of its work.

Can you check config.log to see why it is failing?  Here is the code
that should be checking:

                *)
                AC_MSG_CHECKING([for the pthreads library -l$flag])
                PTHREAD_LIBS="-l$flag"

I don't have any flags here so I can't test that.  Maybe I should try on
FreeBSd.

Also, I am not happy the -D flags appear after the C files.  I might
need to fix that in the Makefiles.

--
  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 4/25/04 8:57 AM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> In config/acx_pthreasd.m4, I see:
>
> acx_pthread_flags="pthreads none -Kthread -kthread lthread \
> -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-conf
> ...
>
> The configure test should be trying -lpthread as part of its work.
>
> Can you check config.log to see why it is failing?  Here is the code
> that should be checking:

I don't see it attempting that test at all, but could be overlooking it.
I'll send you the config.log file.

Wes

wespvp@syntegra.com wrote:
> On 4/25/04 8:57 AM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:
>
> > In config/acx_pthreasd.m4, I see:
> >
> > acx_pthread_flags="pthreads none -Kthread -kthread lthread \
> > -pthread -pthreads -mthreads pthread --thread-safe -mt pthread-conf
> > ...
> >
> > The configure test should be trying -lpthread as part of its work.
> >
> > Can you check config.log to see why it is failing?  Here is the code
> > that should be checking:
>
> I don't see it attempting that test at all, but could be overlooking it.
> I'll send you the config.log file.

OK, I just did some major wacking of the thread stuff and tried it on
FreeBSD 4.9.  It failed because getpwuid() isn't thread-safe on that
platform, and there isn't a getpwuid_r() function, but it did pick up
-pthread as a valid option.

Please test CVS HEAD and report back.  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

On 4/25/04 4:21 PM, "Bruce Momjian" <pgman@candle.pha.pa.us> wrote:

> OK, I just did some major wacking of the thread stuff and tried it on
> FreeBSD 4.9.  It failed because getpwuid() isn't thread-safe on that
> platform, and there isn't a getpwuid_r() function, but it did pick up
> -pthread as a valid option.
>
> Please test CVS HEAD and report back.  Thanks.

No, I still don't see a -lpthread anywhere.  Since it successfully builds
(i.e. no unsatisfied externals for thread support), that would seem to
indicate it isn't building any thread support, wouldn't it?

I'll send you the latest config.out

Wes

> OK, I just did some major wacking of the thread stuff and tried it on
> FreeBSD 4.9.  It failed because getpwuid() isn't thread-safe on that
> platform, and there isn't a getpwuid_r() function, but it did pick up
> -pthread as a valid option.
>
> Please test CVS HEAD and report back.  Thanks.

Maybe -lpthread isn't needed on OS X (10.3)?  I built thread_test, which
compiled without -lpthread and still worked.  How can I be certain
postgresql built correctly with full thread support?



% make
gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -I../../../src/include   -c -o thread_test.o
thread_test.c -MMD
gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
-D_POSIX_PTHREAD_SEMANTICS -L../../../src/port   thread_test.o  -o
thread_test


% otool -L thread_test  (Apple technote says this is the same as "ldd")
thread_test:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 71.0.0)


% ./thread_test
Your errno is thread-safe.
Your system has sterror_r();  it does not need strerror().
Your system has getpwuid_r();  it does not need getpwuid().
Your system has getaddrinfo();  it does not need gethostbyname()
  or gethostbyname_r().

Your platform is thread-safe.