Re: libpq thread safety

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: libpq thread safety
Дата
Msg-id 200403110238.i2B2cqi14318@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: libpq thread safety  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: libpq thread safety  (Manfred Spraul <manfred@colorfullife.com>)
Список pgsql-hackers
Bruce Momjian wrote:
> 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.

Done.

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

What killed the idea of doing ssl or kerberos locking inside libpq was
that there was no way to be sure that outside code didn't also access
those routines.  I have documented that SSL and Kerberos are not
thread-safe in the libpq docs.  Let's wait and see If we need additional
work in this area.

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


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: selective statement logging
Следующее
От: zhuangjifeng
Дата:
Сообщение: why not ADTs?