Re: callback-based reply handling

On Mon, 11 Apr 2005, Kevin Brosius wrote:

> 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.

I've already begun ecore port, and i would say that i've done 30% of the 
work (ecore is really big). But i need to understand more how this stuff 
(xcb reply callbacks) works.

Kevin, i would be glad to discuss with you about that (ecore and xcb), by 
mail or irc.

Vincent