| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Lee Kindness <lkindness(at)csl(dot)co(dot)uk> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: libpq_r |
| Date: | 2003-07-24 14:09:53 |
| Message-ID: | 18502.1059055793@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Lee Kindness <lkindness(at)csl(dot)co(dot)uk> writes:
> Bruce Momjian writes:
>>> My guess is that if the OS has separate threaded libs, we have to mimic
>>> that stuff.
> But there are NO thread primitives/calls in libpq
That's not the point. The point is stuff that isn't necessarily visible
in the source code --- such as what method it uses to get at "errno",
whether it's linked to thread-safe versions of malloc and other libc
routines, etc.
If the OS supplies both libc and libc_r, it is unlikely to be a good
idea to link a threaded libpq with libc, or a non-threaded libpq with
libc_r.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lee Kindness | 2003-07-24 14:32:57 | Re: libpq_r |
| Previous Message | Peter Eisentraut | 2003-07-24 14:04:28 | Re: libpq_r |