[Xcb] xlib / xcb deadlock/block

[Francesco Abbate]

2010/10/18 Rami Ylimäki <rami.ylimaki at vincit.fi>:
>
> I don't think there are any known problems with plain XCB without XLIB. It's
> always better to use XCB directly if you can get rid of XLIB. I'd suggest
> you to port your application to use XCB if at all possible.
>
> If you don't want to port to XCB, one way to work around this problem is to
> use two connections to X server. The original problem happens when you are
> reading events and waiting for request reply (sync) at the same time on the
> same connection. You could probably just wait for events on a different X
> server connection and send your requests and syncs over the other
> connection.
>

Hi Rami,

thank you very much for your help. You suggestion to open a second
connection and to send requests from the thread #2 works very well for
my application.

I've made the tests and it seems to be just fine. What I've done is to
open a second "Display*" with XOpenDisplay and use this latter
connection to send requests from the second thread. To make the
requests I'm sharing the GC, the Window and all the X Resources among
the threads. At the beginning I was not sure if it was going to work
because I'm used to think that these resources are specifically
allocated for a specific display connection. In reality I think that
all these resources are stored in the X server and what we obtain in
the client side is just an identifier number for the resource which is
allocated in the server so I guess it is ok to use them on two
different connections.

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.

I'm putting the list in CC because I think it can be useful for all
the people that may have the same problem.

Best regards,
Francesco