[Xcb] best practice for non-threaded multiple file descriptor event loop.

Josh Triplett josh at joshtriplett.org
Sun Jul 12 11:32:30 PDT 2015

On Sun, Jul 12, 2015 at 05:27:38PM +0000, Bart Massey wrote:
> xcb_get_file_descriptor() does what you think it does. The description in
> the documentation is based on the fact that xcb_connect_to_fd() is always
> called to open a connection: the "you" is a bit confusing there and should
> probably be fixed.
> Josh's email is mostly talking about selecting on replies rather than
> events.

I was talking about either replies or events; in either case, it's
possible for XCB to have already read them off the wire and buffered
them, so the fd no longer has data, but you shouldn't block.

> X mixes replies and events on a single TCP stream, and XCB demuxes and
> queues them. You don't really have access to the event queue like in Xlib
> because that is error-prone and expensive. You will have to be kind of
> careful with the selects and use the non-blocking event grabber
> xcb_poll_for_event() to get this to work. It will be fiddly to get right,
> but as far as I can remember it should work. If you are careful, the only
> time XCB should block is waiting for a server response when you force a
> cookie early. XCB doesn't really care if you block in your own code.
> while true
>     select on fd
>     if fd is x connection
>         while xcb_poll_for_event returns an event
>             process the event
>     else
>         handle the fd however

That *should* work, assuming no other thread touches XCB, and assuming
you check for outstanding replies in addition to events whenever you
have request cookies that you don't have the replies for yet.

- Josh Triplett

More information about the Xcb mailing list