libpq thread safety - Mailing list pgsql-hackers

From Manfred Spraul
Subject libpq thread safety
Date
Msg-id 4001594F.6060304@colorfullife.com
Whole thread Raw
Responses Re: libpq thread safety  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: libpq thread safety  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
libpq needs additional changes for complete thread safety:
- openssl needs different initialization.
- kerberos is not thread safe.
- functions such as gethostbyname are not thread safe, and could be used 
by kerberos. Right now protected with a  libpq specific mutex.
- dito for getpwuid and stderror.

openssl is trivial: just proper flags are needed for the init function.
But what about kerberos: I'm a bit reluctant to add a forth mutex: what 
if kerberos calls gethostbyname or getpwuid internally?
Usually I would use one single_thread mutex and use that mutex for all 
operations - races are just too difficult to debug. Any better ideas? 
Otherwise I'd start searching for the non-threadsafe functions and add 
pthread_lock around them.
Actually I'm not even sure if it should be a libpq specific mutex: what 
if the calling app needs to access openssl or kerberos as well? Perhaps 
libpq should use a system similar to openssl:

http://www.openssl.org/docs/crypto/threads.html

--   Manfred



pgsql-hackers by date:

Previous
From: Dennis Bjorklund
Date:
Subject: Re: psql \d option list overloaded
Next
From: Manfred Spraul
Date:
Subject: PQinSend question