[Xcb] xlib / xcb deadlock/block

[Peter Harris]

On 2010-10-19 04:54, Francesco Abbate wrote:
> Talking about a rewriting of my application to use xcb directly
> instead on xlib I have to confess that it is hard to me the see
> advantages of this change. I guess that if the xcb backend is more
> efficient I already have this advantage because the new xlib is based
> on xcb.

The main advantage of xcb (in terms of efficiency[1]) is the ability to
execute requests that expect replies asynchronously.

This means that you can have multiple XGet* or XQuery* type commands
in-flight at the same time, saving round trips and avoiding latency. If
you use Xlib (even xcb-based Xlib) the API promises to block until the
reply is available, so you don't get this advantage.

The reason Xlib is based on XCB now is so you can call XGetXCBConnection
on your Display to get an xcb_connection_t. This allows you to rewrite
sections of your app that would benefit from reduced net latency without
having to rewrite your entire app.

If your app does a lot of querying, the benefit can be dramatic. If your
app does not, the benefit can be close to zero.

See http://blogs.sun.com/alanc/entry/porting_xwininfo_to_xcb for a more
thorough discussion.

I hope this helps clarify the efficiency advantage (or lack thereof,
depending on your app) of the XCB API.

Peter Harris

[1] Other advantages include a clean API that does not hide what is
really going on (how many aliases for ChangeGC does Xlib have?), and
sane error handling (no setjmp).
-- 
               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