[Xcb] Doubled API size (was: xcb-util: ewmh library)

[Peter Harris]

Jamey Sharp wrote:
> But it seems that those cases are rare, so doubling the size of the
> API and the implementation was probably a poor choice. What could we
> have done instead?

I assume that this is a rhetorical question, but it has been tickling my
brain.

We could have avoided doubling the size of the generated API by adding
two new core functions:
 - xcb_check_cookie(connection, cookie) - only valid if called
immediately after a default-unchecked function, before calling any other
functions. With this restriction, we'd know that there is no possible
way for the error to have already been read.
 - xcb_uncheck_cookie(connection, cookie) - moves any associated error
(or future error) back to the error queue. Works on both default-checked
cookies and xcb_check()'d cookies.

This is academic, of course, as we don't want to break the API now.

Given those two functions, this becomes an attractive function:
 - xcb_discard_cookie(connection, cookie) - performs an
xcb_uncheck_cookie(), and discards any reply (or future reply).

In particular, xcb_discard_cookie would be useful for garbage collected
languages that want to bind to C libxcb instead of implementing their
own XCB core (for interoperability reasons). When toying with a Lua
wrapper, I kept having to *_reply(cookie) in the cookie garbage
collector in order to avoid leaks. It would be more efficient to not
wait for the network.

I'm not sure how many applications issue speculative requests in order
to avoid future latency, but I could have used discard_cookie when
converting xlsclients (see the "drain stale replies" loop).

Peter Harris
-- 
               Open Text Connectivity Solutions Group
Peter Harris                    http://connectivity.opentext.com/
Research and Development        Phone: +1 905 762 6001
pharris at opentext.com            Toll Free: 1 877 359 4866