From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq thread safety |
Date: | 2004-02-11 21:49:11 |
Message-ID: | 200402112149.i1BLnBS18209@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >However, we really have two types of function tested.
> >The first, strerror, can be thread safe by using thread-local storage
> >_or_ by returning pointers to static strings. The other two function
> >tests require thread-local storage to be thread-safe.
> >
> >
> You are completely ignoring that libpq is a library: what if the app
> itself wants to call gethostbyname or stderror, too?
> Right now libpq has it's own private mutex. This doesn't work - the
> locking must be process-wide. The current implementation could be the
> default, and apps that want to use gethostbyname [or kerberos
> authentication, etc.] outside libpq must fill in appropriate callbacks.
I never thought that far. I have applied a patch to remove the thread
locking and throw an error in case a thread-safe function can not be
found.
I also changed the thread-safe variable to have a separate variable for
each function so that *_r functions can be better selected.
--
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 21:54:29 | Re: libpq thread safety |
Previous Message | Bruce Momjian | 2004-02-11 21:39:13 | Re: Transaction aborts on syntax error. |