On 3/30/07, Bill Stouder-Studenmund <wrstuden@netbsd.org> wrote:

> > from multiple threads... now, since (in my sample) the XOpenDisplay
> > returns a pointer which is only being accessed from the very thread
> > that called XOpenDisplay, then AFAIK one does not need to call
> > XLockDisplay...
>
> I don't think so. You explicitly told X that you're in a multi-threaded
> environment, and for X that means locking. If an X library call expects
> something to be locked, you need to have it locked before making the call.

I am not sure that I agree... What I think I have explicitly told X is
that I will be using XLockDisplay/XUnlockDisplay at SOME points in my
code to prevent other threads from accessing the Display structure...
it does not mean (AFAIK) that I am then obliged to lock EVERY point of
access of the Display structure (e.g. when no other thread touches the
display). I have not seen any doco which would state  something
similar to "if you plan to call XLockDisplay at some point, then you
must call XInitThreads first and then you must call XLockDisplay at
every point/time you access Display retured by XOpenDisplay - even if
no other threads are going to use the display". Moreover, I haven't
seen any doco which would state that "you must have Display locked
before calling a given Xxxx function if you called XInitThreads
earlier on", nor have I seen any doco which would say "if in
multithreaded environment - you must lock Display at all times, even
if no other thread is going to access it"... but then again I might be
missing something :-)

From a higher level of understanding, what I think the behaviour of
XLockDisplay/XUnlockDisplay to be is that *inside* XLib, every call
that touches a given Display structure calls lock/unlock (on XLib's
internal mutex initialised with XInitThreads which may or may not be
allocted on 1:1 basis with a given Display structure) around its code
(so it  does its own locking for anything it will unlock later) - this
automatically locks out other (e.g. application's) threads that might
be trying to touch the same Display. This offers a unique
synchronisiation capability that cannot be implemented by Xlib clients
alone - because there is no way for the client to say where the
internal Xlib's thread of execution is... and the best way (IMHO) to
implement it would be the aforementioned description... But then again
- I am rather ignorant... I think I might ask this question on the
Xlib's developers forum :-)

> While you are right that there will be no other thread you need to lock
> out from accessing the display, that doesn't mean you can ignore the
> locking that the library expects. The error you're getting is "Unlocking

I dont think that the library actually expects the locking you
describe... in that I think the library would do its own locking on
the section of the code which it expects to unlock later...

> Try the locking.

OK, ok ... I have - no difference at all - still the same problem (see
earlier posts for log outputs, etc), here is the updated code...

#include <unistd.h>
#include <pthread.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xatom.h>

#include <GL/glx.h>
#include <GL/gl.h>

void * blockingThread (void *opaque)
{
       Display *dpy (XOpenDisplay (NULL));
       if (dpy != NULL)
       {
               XLockDisplay (dpy);
               if (glXQueryExtension(dpy, NULL, NULL))
               {
                       int majorVersionNumber, minorVersionNumber;
                       glXQueryVersion (dpy, &majorVersionNumber,
&minorVersionNumber);
               }
               XUnlockDisplay (dpy);
       }
       return NULL;
}

int main ()
{
       if (!XInitThreads ())
              return -1;
       pthread_t blockingThreadId;
       pthread_create (&blockingThreadId, NULL, blockingThread, NULL);
       sleep (10);

       return 0;
}

> Oh, I haven't had a chance to test this program on macppc.

:-)