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

[Eamon Walsh]

Peter Harris wrote:
> On 2010-02-01 20:44, Jamey Sharp wrote:
>   
>> On Tuesday, February 2, 2010, Peter Harris <pharris at opentext.com> wrote:
>>     
>>> This feels like duplication of effort to me. XCB already keeps a queue
>>> of requests that have been issued. It already tracks which replies it
>>> should discard (ignore) in the future, too.
>>>
>>> Therefore, what do you think of the attached? It adds
>>> xcb_discard_reply(), which does free(wait_for_reply(cookie, NULL))
>>> except it doesn't block when the reply hasn't been received yet.
>>>       
>> I can't review the patch properly at the moment, but it looks
>> promising. Does it correctly handle discarding the multiple replies of
>> a ListFontsWithInfo or similar?
>>     
>
> Yes. It even works if you xcb_list_fonts_with_info_reply a couple of
> times, decide you have found the font you're interested in, and
> xcb_discard_reply() the rest with a single function call.
>
>   
>> Does it work if the request didn't
>> originally queue a request record, as happens when there are no flags
>> or workarounds?
>>     
>
> Ah, good point. No, it does not work with _unchecked() calls. I didn't
> test that because reply-expecting calls have the 'checked' flag by default.
>
> Is discarding _unchecked replies important? If so, I can fix it. If not,
> I can document it.
>   

The use case that motivated this thread is that in xpyb, XCB cookies are
represented by objects, and when a cookie object gets garbage collected,
we want to make sure that the associated reply (or replies) have been
cleaned up.  It would be great if I could just blindly call a function
from the cookie destructor to do this, regardless of what the request is
or what the user has done so far.  So I'd say that ideally yes, it
should work for _unchecked calls.

>   
>> Assuming the patch is correct, I'd take it.
>>     
>
> My current beef with the patch is that it requires horrible typecast
> gymnastics to convert a specific cookie type to an xcb_void_cookie_t.
> I'm not sure if that can be fixed without either breaking existing apps
> or adding a gazillion request-specific discard functions.
>
> Peter Harris
>   

In response to the discussion of the cookie sequence number being
"opaque," in a strict C language sense this is not true.  The sequence
field is visible in the public API.  Within xpyb, xcb_wait_for_reply()
is being used at present.  So, I'd say it would be fine to use the
sequence directly in another API call.

--Eamon W.