[Xcb] How to wake up the GUI thread in XCB?

[Uli Schlachter]

Am 23.05.2015 um 11:58 schrieb Cosmin Apreutesei:
>>> Generally if you want anything fancy (selecting on multiple file
>>> descriptors, custom timeout, etc) you would
>>> xcb_poll_for_queued_event()[1] until it returns NULL, then
>>> xcb_get_file_descriptor() and do your own select/poll/epoll/etc.
> 
> For that I need to connect using xcb_connect_to_fd(), right? Does that
> have performance implications over xcb_connect(NULL, NULL) ?

Nope and nope.

You can always use xcb_get_file_descriptor() on an xcb connection, even when the
connection was created with xcb_connect().

>> However, this only works reliably in single-threaded code.
> 
> So, to the problem of  "xcb + timers", it looks like I have two options:
> 
> 1) main thread blocked in select(xcb fd + other timer fds); other
> threads must open a new connection and pass a custom message to one of
> the windows if they want to wake up the main thread, as to avoid the
> aforementioned problem with prefetched events.

Almost. XCB is fully thread-safe. You can just use the same connection from all
of your threads. You only have to make sure that there are no other threads
while you call xcb_disconnect().

> 2) Qt's way: main thread blocked in a synchronized queue; secondary
> xcb thread pumping xcb messages into that queue; yet another thread
> selecting on timerfds posting timer-expired events into that same
> queue. Other threads can post messages into that queue too as needed.

I don't think Qt has that many threads. I think the main thread does timer
handling as well. At least I don't see a reason why not.

So, for example:

Main thread blocked in poll() for timer handling and all other sockets etc.
Additionally, you include the read end of a pipe here. When you event pumping
thread wants to wake up the main thread, it writes a byte with value 42 into the
pipe.

> Seems like the 2nd solution has some advantages, albeit being more
> complicated: 1) allows sharing the xcb connection between threads (if
> I'll ever need that); 2) no need for spawning xcb connections +
> sending custom messages to wake up the main thread.

Sorry, I don't really see that much of a difference between the two approaches.
The difference seems to be "main thread blocked waiting on some thread
synchronisation primitive" vs "main thread blocked in select/poll/...". The
XCB-related bits are pretty much the same in both cases.

> Thanks for all the help.
> (and please correct me where I did the assessment wrong)

Cheers,
Uli
-- 
“Some people are worth melting for.” - Olaf