[Xcb] callback-based reply handling

[Kevin Brosius]

Jamey Sharp wrote:
> 
> 
> 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.
> 

This sounds like a useful way to go for E's ecore.  Thanks Jamey! 
Hopefully I'll get back to this, or Vincent will get a chance to explore
it soon.

-- 
Kevin