Re: [Dri-devel] Re: OpenGL and the LinuxThreads pthread_descr structure

[Gareth Hughes <gareth dot hughes at acm dot org>]

Keith Whitwell wrote:
 >>
>>2) last time I looked, libGL.so was linked unconditionally against
>>   libpthread. This is punnishing all non-threaded apps, weak undefined
>>   symbols work very well
> 
> 
> This is because we currently use the standard way of getting thread-local-data
> and detecting multi-thread situations.  I'm not sure how Gareth is able to
> detect threaded vs. non-threaded situations without making any calls into the
> pthreads library, but once you know which one you're in, with his trick, you
> don't need to make any more.
> 
> Currently we do something like this in MakeCurrent:
> 
> void
> _glapi_check_multithread(void)
> {
> #if defined(THREADS)
>    if (!ThreadSafe) {
>       static unsigned long knownID;
>       static GLboolean firstCall = GL_TRUE;
>       if (firstCall) {
>          knownID = _glthread_GetID();
>          firstCall = GL_FALSE;
>       }
>       else if (knownID != _glthread_GetID()) {
>          ThreadSafe = GL_TRUE;
>       }
>    }
>    if (ThreadSafe) {
>       /* make sure that this thread's dispatch pointer isn't null */
>       if (!_glapi_get_dispatch()) {
>          _glapi_set_dispatch(NULL);
>       }
>    }
> #endif
> }
> 
> where _glthread_GetID() is really pthread_self().
> 
> How do you detect threading without making these calls to libpthreads.so?

The important point is that you don't really need to detect threading 
anymore.  The Linux OpenGL ABI states that multithreaded apps must link 
with pthreads.  Thus, at startup, you can detect the presence of 
pthreads or otherwise.  Basically, if pthreads is present, you just use 
the pthread_descr that it set up, otherwise you create a dummy one and 
plug it into the segment registers (or whatever) and be done with it. 
 From that point on, you don't care how many threads there are. 
Accessing "global" data is always done the same way, independant of the 
number of threads running.

In any case, it would be great to remove the need of apps that link with 
libGL to also link with pthreads, and to force the use of pthreads even 
for single-threaded apps.

> The thing that really bites with -fpic is the bs you have to go through to get
> access to static symbols (forgive my loose terminology) like static variables
> or other functions you want to call.  Gareth's trick means that two very
> important variables avoid this, but it's still going to be necessary to call
> other functions often enough...

I'd like to hear a strong arguement as to why you *would* want to link 
with -fpic.  Like Keith, I'm also not familiar with some of the more 
in-depth aspects w.r.t. relocation/fpic etc, so feel free to enlighten us.

-- Gareth