Re: thread_test.c problems

> 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