Re: libpq thread safety

Bruce Momjian wrote:

>How can we test if libpq needs to call that?  Seems that is an issue
>whether we are threaded or not, no?
>  
>
I think it's always an issue: in the non-threaded case, it's just not 
fatal. At least some openssl init functions are protected with "if 
(done) return; done = 1;", and it the worst case, it's a memory leak.
With threaded apps,  it might corrupt a concurrent ssl transaction. 
Perhaps PQenableSSLLocks could handle that case, too - a special flag 
for skip SSL_library_init().

>There is a new test program in src/tools/thread that needs to be run for
>every platform for 7.5.  We can't use the 7.4.X tests because it didn't
>report individual function tests, just one general value.  We need
>individual test reports for 7.5.  Run the test program and post the
>results and I will get it updated.  The test output on my bsd/os machine
>is:
>  
>
RedHat Fedora Core 1 and Debian 3.0 both report

<<
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
<<
The uname's are
Linux <snip> 2.4.25-1-686 #1 Tue Feb 24 10:55:59 EST 2004 i686 unknown 
unknown GNU/Linux
and
Linux ab 2.4.22-1.2174.nptl #1 Wed Feb 18 16:38:32 EST 2004 i686 i686 
i386 GNU/Linux

Both glibc 2.3.2, one with nptl, one with linuxthreads as the pthread 
library.

--   Manfred