Xlib and openGl in multithreading

The basic X11 program is always something like that

     XNextEvent(d, &event);
     event management(event);

this works, but the manage event can be slow and freeze for some time the render.
What I’m trying to do is to decouple event management and rendering in two threads.



  XNextEvent(d, &event);

In this way the thread two will wait for event (and don’t need polling) while the thread one will render the scene without freeze.
Theoretically… what’s append is that the thread2 is waiting for event and put a lock on the whole Xlib while thread1 is trying to do glXSwapBuffer but the Xlib are locked by thread 2.

There is a solution on this problem?

It should work if you either call XInitThreads() or use a separate Display* connection for each thread.

Alternatively you can use one thread and poll for events using:

while( XPending( display )) { XNextEvent( display, &xEvent ); …; }

Edit: I just saw that you already do the latter. Why is this slow? Is it your event processing code?

Thank for the answare, but I’m already using XInitThreads (without it crash).
And using two separate display connection won’t works. I have to create the windows using a connection and receiving event in another.

d1 = XOpenDisplay()
d2 = XOpenDisplay()

win = XCreateWindow(d1)
oglCtx = glXCreateContext(d1)
startRenderThread(win, oglCtx)


This way I’ll never receive event from the window.

I’m writing an framework for LUA (lunatic.sourceforge.net), so the manage event will call a lua function. Also cause the whole code is driven by script is not forbidden to create two or more windows.
I’m still making some test to check if this is possible.
Here the whole test code -> http://pastebin.com/ffwktc53

Need the c++0x standard and gcc 4.5 to compile
gcc xthread.cpp -lX11 -lGL -lstdc++ -pthread -std=c++0x -g -o xt

I have put a usleep(16000) in the render queue and now it works fine event with more windows.
This look like a X11 bugs, I’ll try to ask on Xlib mailing list.

Waiting for wayland… >_>

edit: work fine means that I didn’t get deadlock, but the problem is not solved

And here it is the bug still unsolved after more than one year.

Excellent… now my application is not thread safe. :-/

Now using XLib-Xcb work correctly.


I create the display and the openGl context using Xlib and then wait for the event using XCb. I made some test with 3 concurrent window and everything running smooth.

Who was the one that said “I never found a bug in X”? :smiley:

If someone want more detail I’ll write a tutorial on my blog.

man XSelectInput

Have you thought about doing the CPU-intensive event processing in a second thread, i.e, doing all X/glX stuff in the main thread and dispatch the work to a second thread?

Thanks, I didn’t know about XSelectInput, I’ll give it a try.
Yes, I also thought about running lua in another thread but also LUA is not thread safe too.
Cause is lua that run my code as an extension I have to make a lot of workaround to run the lua code on another thread.

Actually I’m satisfied with the Xcb solution, I’ll try the solution with two X connection using XSelectInput

I never had such problems with X events.

Can you develop more ? Like, what is your system ? Can you provide a demo of your issue ?

I get the problem both on Ubuntu 10.10 64-bit Gnome driver nVidia
and Fedora 14 32-bit Xcfe driver Intel. Both with kernel 2.6.35

The problem arise when Xlib is implemented with Xcb. Xcb lock the X connection while waiting for event locking the other thread.

I have posted the whole source in the third message if you wanna try it.

Changed distro… and BAM the same problem again… :smiley:
The only reliable solution is the one suggested by aile with N X connection. One for read the event and one for each window.

Here the full code:

With this solution I have to poll for WM_DELETE_MESSAGE event in the window thread. There is any way to get the ClientMessage in the main thread?

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.