[Xcb] callback-based reply handling

[Barton C Massey]

In message <20050410212138.GY24279 at minilop.net> you wrote:
> To implement the polling support, I had to add a new public function to
> XCB: XCBGetRequestRead returns the last sequence number that the server
> is known to have processed. This sequence number can be compared to the
> one in a reply cookie to determine whether forcing the cookie would
> block. (Requests with multiple replies might still block, but probably
> not for very long...) I'm not sure that this function will remain as-is:
> getting the test for "would-block" right is tricky in the face of 32-bit
> sequence number wraps, and maybe we just want a function that answers
> the "would-block" question. The function I implemented, though, should
> be useful in Xlib, while the "would-block" function might not be.

Do both, unless some reason not to.  We've talked about
having "would-block" forever; I forget why it wasn't already
added.

> If you use the reply thread mechanism, you'll get the best results if
> you can ensure that reply cookies are added in order of sequence number.
> (This is easy to ensure for a ReplyHandlers structure that has all its
> cookies added to it by the same thread.) If cookies are added out of
> order, some might get deferred until a later reply is processed:
> presumably not fatal, but more delay than necessary.

Some reason not to keep the internal queue as a PQ on
request sequence number?  Probably :-).


Awesome work with this stuff, BTW, Jamey.  Thanks!

    Bart