libpq thread safety
От
Manfred Spraul
Тема
libpq thread safety
Дата
Msg-id
4001594F.6060304@colorfullife.com
Список
Дерево обсуждения
libpq thread safety Manfred Spraul <manfred@colorfullife.com>
Re: libpq thread safety Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq thread safety Bruce Momjian <pgman@candle.pha.pa.us>
Re: libpq thread safety Manfred Spraul <manfred@colorfullife.com>
Re: libpq thread safety Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq thread safety Manfred Spraul <manfred@colorfullife.com>
Re: libpq thread safety Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq thread safety Manfred Spraul <manfred@colorfullife.com>
Re: libpq thread safety Tom Lane <tgl@sss.pgh.pa.us>
Re: libpq thread safety Bruce Momjian <pgman@candle.pha.pa.us>
Re: libpq thread safety Manfred Spraul <manfred@colorfullife.com>
Re: libpq thread safety Bruce Momjian <pgman@candle.pha.pa.us>
Re: libpq thread safety Bruce Momjian <pgman@candle.pha.pa.us>
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 по дате отправления