From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq thread safety |
Date: | 2004-02-11 21:58:50 |
Message-ID: | 200402112158.i1BLwoa19675@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Spraul wrote:
> 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
What else needs to be done/documented?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-02-11 22:00:05 | Re: Request for additional SPI functions. |
Previous Message | Bruce Momjian | 2004-02-11 21:54:29 | Re: libpq thread safety |