[Xcb] [PATCH 2/3] Do not block when calling reply() multiple times.

Eamon Walsh ewalsh.mailinglists at gmail.com
Sat Jan 23 02:35:58 PST 2010


Julien Danjou wrote:
> At 1264200432 time_t, Jamey Sharp wrote:
>   
>> I don't understand what this patch is for and am about to be away from
>> e-mail for two weeks. Just wanted to note, though, that there are
>> occasionally X requests where you need to call xcb_wait_for_reply more
>> than once to completely process them. Specifically, there's
>> ListFontsWithInfo and something in the RECORD extension.
>>     
>
> If you mean that xcb_wait_for_reply(cookie) will return 2 differents
> reply in some case, then my patch is bad.
>
> I did not know that. Reading the libxcb source show something like that actually. :)
>
> What bothers me is that I alway assumed one request would have one
> reply, but if it can has multiple, how do you know how many it has? It
> is something written in the spec, or can be arbitrary?
>   

I'm pretty sure the RECORD extension works by issuing a single request,
then receiving an arbitrary number of replies containing the recorded
data from that point on (a second request can be issued to stop the
stream).  So yeah, this patch would break that usage model.

The proper solution here is to add some notation to the XML to indicate
when a request has multiple replies.  This can be passed through to the
generated Python and then the behavior can be tailored to the type of
reply: "single" replies can be cached as the patch does it and the
behavior for multiple replies can remain as it is now, try to fetch a
new reply on each call.

This still leaves open the question of what happens in a multiple-reply
scenario if the Cookie object is freed and more replies arrive afterwards.

--Eamon W.



More information about the Xcb mailing list