[Xcb] callback-based reply handling

[Vincent Torri]

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