[Xcb] Multithreading issues with libX11 / XCB
Bub Thomas
Thomas.Bub at precision-mechatronics.com
Tue Dec 6 06:09:00 PST 2011
I'm having trouble with multithreaded on libX11 XCB.
While our main application is very complex I used the
http://www.opensource.apple.com/source/X11server/X11server-85/mesa/Mesa-7.2/progs/xdemos/glthreads.c
example to make the issues reproducible for everybody.
It uses a main thread doing XNextEvent and a number of n drawing threads doing some glxMakeCurrent, openGL drawing and a glxSwapBuffers in a loop.
Even with one drawing thread configured the application hangs!
The application locks up with the main thread in the xcb_wait_for_event called from _XReadEvents and the drawing thread in xcb_wait_for_reply called from_XReply.
The main thread is holding a lock waiting for an event and the drawing thread waiting to acquire the lock.
When someone new generates an event like resize the openGL window or enter a keystroke the main thread gets an event and the application runs a little further but only until all events are consumed!
This wasn't the case in old libX11 implementations without XCB!
OK I said maybe this is the way it is and I must wait for a new event coming in with XPending before calling XNextEvent and modified the example code.
This helps for a while and the application may run for a while until a race condition makes it fail again
Now the problem is caused by the xcb_io.c method _XEventsQueued called from the main tread via XPending.
The lines:
while((response = poll_for_response(dpy)))
handle_response(dpy, response, False);
if(xcb_connection_has_error(dpy->xcb->connection))
_XIOError(dpy);
at the end of the method eat away the response packet the drawing thread is waiting for in xcb_wait_for_reply called from_XReply.
So the race condition is the drawing thread must be in xcb_wait_for_reply waing for ist replay while the main thread comes along and does it's thing in _XEventsQueued.
Commenting out those lines, mentioned above, help to get the example run endless without a lock up!
The X-Server however can't be started afterwards since the code commented out must be good for something in other cases!
I'm running libX11-1.4.4 libXcb-1.7 on Suse Linux Enterprise Server 1 SP1 on a 4 CPU machine but have seen this also with openSuse12.1 and CentOS 6.
I see this as two separate issues, unless someone tells me different.
Should I open two independent bugs?
Any help welcome.
Thomas Bub
DFT Digital Film Technology GmbH
More information about the Xcb
mailing list