| From: | Manfred Spraul <manfred(at)colorfullife(dot)com> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| 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-10 23:03:05 |
| Message-ID: | 40296329.4030703@colorfullife.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Manfred
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2004-02-10 23:29:36 | Summary of Changes since last release (7.4.1) |
| Previous Message | Bruce Momjian | 2004-02-10 22:32:52 | Re: libpq thread safety |