[Xcb] callback-based reply handling

[Jamey Sharp]

On Sun, Mar 20, 2005 at 04:01:06PM -0500, Kevin Brosius wrote:
> Jamey Sharp wrote:
> > I'm going to throw out the hypothesis here, though, that an app that
> > needs syncs can be re-written into one that doesn't -- one that uses a
> > more event-driven model, for instance, or that gets work done in those
> > round-trips. If the hypothesis is true, and the re-writing isn't too
> > hard, it might be a good idea to do a re-write like that because every
> > sync is obviously going to prevent the thread from doing anything until
> > the server catches up.
> 
> We've had a couple short discussions about architecture and you point
> out the major benefit of XCB we hope to get to, Jamey.  If responses can
> be tied to an expected response queue (I'm guessing), then Sync's can be
> largely avoided, or at least not block in all cases.  We'll have to see
> how it goes. :)

I've just committed a simple library called XCBReply (I'm not all that
creative with names) to the xcb-util module. It allows apps to register
callback functions tied to specific replies arriving. It can be used in
a polling mode, or it can spawn off a thread that calls the reply
handlers. These aren't mutually exclusive, and multiple threads may be
spawned for the same set of handlers for a "thread pool" effect.

The test app I included uses ListFontsWithInfo, which I've finally just
committed to xcb-proto. It works great. :-)

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.

Naming conventions in this library need to be cleaned up, as with most
of the xcb-util code; I hacked it together very quickly. I'd also like
to build a type-safe layer on top of the code that's there now;
everything is currently implemented in terms of XCBGenericReps and such.
Finally, I'd like to allow callbacks for XCBVoidCookies (the current
code would hang) which would be useful for capturing errors from
specific requests.

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.

--Jamey