This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Gareth Hughes wrote:
> 
> 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.

Hmm.  And does libpthreads.so *always* set this up -- is it possible to link
to libpthreads.so but not actually use it, spoofing your detection?

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

I agree.  

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

Me also.

Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]