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
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
