[Xcb] xcb_wait_for_reply deadlocking with xcb_property_changed call
Josh Triplett
josh at joshtriplett.org
Fri Mar 26 14:23:30 PDT 2010
On Fri, Mar 26, 2010 at 03:19:44PM +0100, Nicholas Allen wrote:
> I had a problem a while ago with deadlocking that seems to have been
> solved by moving from xlib to XCB and calling xcb_flush before
> xcb_wait_for_event. However, I recently started experiencing this
> deadlocking again. I've noticed it always happens when I call the
> xcb_property_changed function from the property utils and the deadlock
> happens inside xcb_wait_for_reply.
It wouldn't surprise me at all if the property library has bugs.
> I only recently added this to the code so it could be that I'm doing
> something wrong. The last time I had deadlocking problems it was because
> I wasn't calling xcb_flush before waiting for the next event. Should I
> be doing the same before calling xcb_property_changed function? Or
> perhaps the xcb_property_changed function should be doing this itself
> (this would make more sense to me). Couldn't xcb_wait_for_reply
> automatically flush the connection first to prevent these kinds of problems?
If the property library needs flushes, it should probably handle those
itself.
xcb_wait_for_reply could flush, but it shouldn't; that would force
performance degredation on code that doesn't actually need a flush. For
example, you might send N requests, flush, send M requests, and then
wait for a reply from one of the N requests; you don't need to flush
again before doing that.
- Josh Triplett
More information about the Xcb
mailing list