From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Larry Rosenman <ler(at)lerctr(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: threads stuff/UnixWare |
Date: | 2004-05-12 20:22:58 |
Message-ID: | 28249.1084393378@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Larry Rosenman <ler(at)lerctr(dot)org> writes:
> I was thinking of pq_pthread_* calls, and that function would
> set a static flag for calling either the real pthread_* function
> or a statically named version in libpgport.a that is a single thread
> wrapper.
And how will you avoid having a link-time dependency on the real pthread
function? You muttered about dlsym but how much code will that take,
and what kind of runtime penalty will we incur? (IIRC the pthread
functions are performance critical.)
Even more to the point, can you make it work at all? I seem to recall
from the prior discussion that -Kpthread actually changes some code
generation details on that platform. Are -Kpthread and non -Kpthread
libraries interoperable at all?
> I know, this sucks, but, I don't see any other way, other than linking
> *ALL* libpq-using programs (including initdb and friends) with -K pthread.
-Kpthread doesn't sound that bad to me, as long as it's documented.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2004-05-12 20:25:51 | Re: threads stuff/UnixWare |
Previous Message | Larry Rosenman | 2004-05-12 20:04:22 | Re: threads stuff/UnixWare |