James Carlson <[email protected]> writes:
> Rainer Orth wrote:
>> James Carlson <[email protected]> writes:
>>> That's all changed now that the threads libraries have been folded into
>>> libc. There's no such thing as purely unthreaded any more -- just
>>> multithreaded applications that happen to have only one thread -- and
>>> all of the calls are "live" all of the time.
>>
>> Right. I think I'm going for linking -lpthread and/or -lthread with
>> -pthread/-threads -shared in GCC even on Solaris 8 and 9 and add
>> -L/usr/lib/lwp -R/usr/lib/lwp on Solaris 8. The alternative of having
>> the user specify all that (and spread the necessary knowledge all over
>> the GCC tree) is just unacceptable.
>
> You might not want to do that. You'll be forcing single-threaded
> applications on those older OSes to become suddenly and rather
> unexpectedly multi-threaded, regardless of what the application author
> had intended.
I'm not: this only happens if the user links a shared library with
-pthread. I'm using this in a couple of places when building GCC
runtime libraries: instead of doing the same dance over and over again
(link with -lthread on S8/9 if using TLS, adding -L/-R /usr/lib/lwp on
S8) just doesn't seem right. For executables, -pthread already handles
this just fine. Why should the user need to know tons of Solaris
implementation quirks when building shared libraries?
> If you're lucky, the result will merely be slower execution times. If
> you're unlucky, you'll trigger latent behavior that actually breaks
> something. (It's not *completely* unknown for single-threaded
> applications to have latent MT code that -- due to the stubs -- does
> nothing, but that when activated with a real threads library actually
> has bugs that cause deadlocks or worse.)
I cannot of course guarantee that, but what's the alternative?
> As for the rest of what you're saying, I guess I'm just confused. I
> don't see why you'd have to do anything special for those older
> releases. The stubs in libc should take care of it for you and
> shouldn't require any heroics.
Unfortunately not: for thread-local storage, the compiler generates
calls to the __tls_get_addr and ___tls_get_addr functions. Before the
unified process model in Solaris 10, the implementations only lived in
libthread.so, not even in libpthread. So if you want to use TLS, you
need to link with -lthread, and I don't think it's appropriate that
users have to know this implementation detail. Since TLS only makes
sense in multithreaded programs, there's no extra penalty to be paid.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
_______________________________________________
tools-compilers mailing list
[email protected]
