[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