[Xcb] (no subject)

[Adrian Ratnapala]

Hello,

I'm trying to figure out how far I can push XCB's promise to be
"thread safe".   In
particular I want to know what happens when more than one thread is waiting for
replies from the server.  Right now I am running into deadlocks and crashes.

The background is that  I am trying to write a GUI toolkit native to
the Go language.
Since Go encourages concurrency, I'd like as much behaviour  as
possible to be usable
from multiple threads (and also "goroutines").  XCB seems to be a good
choice for
concurrent access to X11.    I want  to have a single thread (or maybe
goroutine)  polling
for events but I want to make concurrent threads to be able to do
stuff  using  *_checked()
requests.

The specific problems are:

* The event thread (E) starts but a separate thread (W) will create
and map a window.
* W successfully sends CreateWindow and gets the reply with
`xcb_check_request()`.
* W sends the MapWindow requests.
* E calls `xcb_wait_for_event()`
* W calls `xcb_check_request()` for the MapWindow.
* DEADLOCK.

I think there is no deadlock when `xcb_check_for_request()` comes
before `xcb_wait_for_event()`.
If I use a mutex to ensure `check_for_request()` doesn't happen until
after `xcb_wait_for_event()`
returns, then the deadlock seems to go away.

The other problem is intermittent crashes when thread W tries to close
the display.
At that point thread E is still blocking on `xcb_wait_for_event()`.
The crash happens
inside XCloseDisplay  (I am using XInitThreads(); XOpenDisplay();
XGetXCBConnection()).
Thread E calls `xcb_connection_has_error` immediately after the event
wait -- perhaps this
is not safe to do while after XCloseDisplay() is called.












-- 
Adrian Ratnapala
mobile: +49 1515 277 0000

NGBitS GmbH
Rainer Strasse 7
83104 Ostermünchen

Web: www.ngbits.com