Manfred Spraul wrote:
> 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.
Right, and it is moving into a compatibility function in 7.5 where it
will be a local function variable.
> - pg_krb4_init(): Are the kerberos libraries thread safe? Additionally,
> setting init_done is racy.
No idea.
> - 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.
Seems kerberos isn't.
> - PQoidStatus: uses a static buffer.
Yes, known documented problem.
> - libpq_gettext: setting already_bound is racy.
Does that happen in different threads?
> - 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.
Oh.
> 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.
Oh, seems like a TODO here. We already know how to do thread locking in
port/thread.c so maybe we just need to add some locks in there.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073