
>From SCO:

We probably want to be aware of this for a threaded libpq for 7.4.

LER

------------ Forwarded Message ------------

Larry Rosenman wrote:
>
>
####identity suppressed for NDA reasons####
> wrote:
>
>>> So, what I was doing was probably screwing up the syscalls that
>>> libthread wraps?
>>
>> Or possibly, in one context, something behaves one way, and assumes a
>> certain stack/process layout, and in another context its different. I
>> cant be more quantitive than that, its very murky, but mixing things that
>> are -Kpthread without things that are -Kpthread is rather like putting
>> your head down the barrel of a canon and daring the canonball to   hit
>> you if it can. Sometimes you may be lucky, the gunpowder will be wet. If
>> its not ...
>>
>> Kean
>
> are the restrictions/recomendations for -K[p]thread documented, i.e. not
> to mix/match
> -K[p]thread code with non- -K[p]thread code?

Here's the reply I got from the expert ...

There are two effects of -Kthread, the first causing differences
in headers through the -D_REENTRANT macro definition.  A change
characteristic of this is errno's mapping to a function call plus
dereference instead of just accessing the single global object.
Another typical change is to turn off thread-unsafe function-like
macros in favor of real function calls.  See <stdio.h> for example.

The other effect is at link time.  Here -Kthread causes some
libthread to be needed, and also optionally includes additional
static objects (like values-pthread.o).

We strongly suggest that only the a.out have libthread needed,
even if a shared library requires libthread.  If libthread is
not present right from the start at the "top level" bad things
will almost always happen when it comes along later.

So, regarding mixing, obvious problems will occur if, for example,
a function is not built -D_REENTRANT and looks at errno's value,
and happens to be called on a non-initial thread.  It will be
examining the initial thread's errno value instead of the one it
should have been using.  Also, if you use a thread-unsafe macro
in a threaded program, you could end up causing difficult-to-
diagnose damage to shared data structures.

On the other hand, anything built -D_REENTRANT is supposed to work
just fine intermixed with other objects in a nonthreaded application.
If this weren't the case, we'd need multiple versions of almost all
of the system shared libraries!

So, the bottom line is, unless you're very sure you know what
you're doing, if an application is threaded, all parts of the
application, even dlopen()d shared libraries, should be built
with -Kthread.  And, be sure that the a.out needs libthread!

PS (this is Kean again) whwta he means by "needs" is if you dump -Lv
program you should see libthread.so.whatever as a NEEDED library.



--------- End Forwarded Message ----------



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




Tue, 15 Jul 2003 16:22:13 -0500
Larry Rosenman <ler@lerctr.org>
Threads considerations on UnixWare 7.1.3