Re: libpq thread safety

Manfred Spraul wrote:
> 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().

I see.

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

template/linux updated.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073