Re: threads stuff/UnixWare

--On Wednesday, May 12, 2004 16:22:58 -0400 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:

> 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.)
The first call to ANY of the pthread_* functions would set the flag, and
would cache the dlsym() info.

>
> 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?
Yes, this is how libc deals with it.

We wouldn't have a hard symbol for the pthread_* calls.

I can ask the compiler guys at SCO if you want.

>
>> 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

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749