libpq thread safety

Поиск
Список
Период
Сортировка
От Manfred Spraul
Тема libpq thread safety
Дата
Msg-id 3FB943E4.90508@colorfullife.com
обсуждение исходный текст
Ответы Re: libpq thread safety
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Optimizer optimizer may be worth a look-see
Следующее
От: Daniele Orlandi
Дата:
Сообщение: A big thanks to SuSE