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

[Jamey Sharp]

On Saturday, January 23, 2010, Julien Danjou <julien at danjou.info> wrote:
> At 1264242958 time_t, Eamon Walsh wrote:
>> The proper solution here is to add some notation to the XML to indicate
>> when a request has multiple replies.

My ancient m4 bits had that feature at some point, but eventually I
decided XCB should behave the same way for all replies, for
simplicity, and at some point the annotations disappeared. I had
another annotation indicating whether Xlib's request-combining
optimization (see XDrawPoint source, for example) was safe for a
particular request type, and it disappeared the same way.

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

Don't let me interfere with innovation, but I'd think consistency
would be preferable.

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

Let me suggest an alternate strategy that works for all requests: keep
a queue of requests that your binding has issued to XCB. Then, when
the application forces a reply, also force all previous replies. You
can be sure the earlier requests won't block. To handle multi-replies,
keep forcing a cookie until you get NULL back.

The non-thread-safe request queue API I proposed a couple months ago
could be used to make this more efficient; I'd really like to see
somebody try it. ;-) Even using current XCB API though, each force
will be expected constant time, so not so bad.

Jamey
who is still in New Zealand, which surprisingly has no wi-fi in its
many rural farming towns.