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