| From: | Manfred Spraul <manfred(at)colorfullife(dot)com> | 
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | libpq thread safety | 
| Date: | 2003-11-17 21:55:48 | 
| Message-ID: | 3FB943E4.90508@colorfullife.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches | 
Hi,
I've searched through libpq and looked for global or static variables as 
indicators of non-threadsafe code. I found:
- Win32 and BeOS: there is a global "ioctlsocket_ret variable, but it 
seems to be a dummy variable that is always discarded.
- pg_krb4_init(): Are the kerberos libraries thread safe? Additionally, 
setting init_done is racy.
- pg_krb4_authname(): uses a static buffer.
- kerberos 5: Is the library thread safe? the initialization could run 
twice, I'm not sure if that's intentional.
- pg_krb4_authname(): relies on the global variable pg_krb5_name.
- PQoidStatus: uses a static buffer.
- libpq_gettext: setting already_bound is racy.
- openssl: According to
http://www.openssl.org/docs/crypto/threads.html
libpq must register locking callbacks within openssl, otherwise there 
will be random corruptions. Additionally the SSL_context initialization 
is not properly synchronized, and SSLerrmessage relies on a static buffer.
PQoidStatus is already documented as not thread safe, but what about 
OpenSSL and kerberos? It seems openssl needs support with callbacks, and 
according to google searches MIT kerberos 5 is not thread safe, and 
libpq must use mutexes to prevent concurrent calls into the kerberos 
library.
--
    Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniele Orlandi | 2003-11-17 22:28:34 | A big thanks to SuSE | 
| Previous Message | Erik Trulsson | 2003-11-17 20:21:09 | Re: 4 Clause license? | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-11-17 21:59:52 | Re: initdb copyright notice | 
| Previous Message | Neil Conway | 2003-11-17 21:15:25 | Re: initdb copyright notice |