Question

I am running 3 instances of a JUCE-based multithreaded OpenGL application on one machine - each of the instances is connected to a separate X display. The main application thread calls XInitThreads followed by XOpenDisplay to the appropriate display. A different thread is then used for the main rendering loop. The 3 instances of the application are initialized after each other, so that one is finished with the graphics setup when the next is starting up.

In 80% of the cases everything starts up fine, but sometimes in the second and/or third instance of the application the 4th call to glXMakeCurrent (which is also the 1st one made from a different thread than the one on which the connection was initialized) never returns. X threads have been initialized, the threads are using locks, and right before the call to glXMakeCurrent the X Display is locked via XLockDisplay (and unlocked after the call returns).

I made sure that each application uses the correct display & context. If it was purely related to problem of multiple threads accessing the same display connection then it should be equally likely that the first instance encounters this problem - but it never does.

Any ideas why glXMakeCurrent may not return, even though it has exclusive access to its X display?

Was it helpful?

Solution

In fact, I was wrong, the problem appears to have been caused by a missing lock on the JUCE OpenGL context. Hence, the X display lock was acquired correctly, but the context to which it was supposed to be mapped was (in the problem cases) being accessed concurrently by the other thread, causing glXMakeCurrent to deadlock.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top