[Xcb] Why is an explicit xcb_flush needed?

[Josh Triplett]

I can think of only a few things that could allow
xcb_wait_for_reply to block forever:

- A bug in XCB.
- A bug in the X server.
- Someone grabbing the X server.
- Some kind of corruption or severe misuse caused by the calling code
  (for instance, forking and trying to use the connection from both
  processes).

Any of those seems possible.  A symbol-enabled backtrace with gdb would
probably nail the first or last, and the xtrace plus the backtrace
should nail the second.  As for the third, hopefully you can rule out
the possibility of an XGrabServer somehow? :)

- Josh Triplett

On Tue, Mar 30, 2010 at 09:36:24AM +0200, Nicholas Allen wrote:
> Ok, thanks for the explanation. If that's the case then this deadlocking
> bug I'm experiencing is most likely in the core XCB library and not the
> properties utility library then right? When I get this deadlock the
> stack trace shows that xcb_property_changed calls xcb_wait_for_reply and
> this never returns. If a flush is not needed before xcb_wait_for_reply
> then it can't be because the property library is not flushing correctly.
> 
> Cheers,
> 
> Nick
> 
> Josh Triplett wrote:
> >
> > You don't need to call xcb_flush prior to xcb_wait_for_reply;
> > xcb_wait_for_reply will flush if you try to wait on a reply for a
> > request that XCB hasn't sent yet.
> >
> > You need to call xcb_flush prior to xcb_wait_for_event, if and only if
> > you expect an event that will only occur after XCB sends a particular
> > request, and you haven't done anything else to guarantee the flush of
> > that request.
> >
> > Does that make sense?
> >
> > - Josh Triplett
> >   
> 
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb