[Xcb] Feature Request: Function "xcb_test_for_event"

[Josh Triplett]

On Wed, Apr 10, 2013 at 06:38:32PM +0200, Uli Schlachter wrote:
> Hi,
> 
> On 09.04.2013 06:14, Josh Triplett wrote:
> > On Mon, Apr 08, 2013 at 07:52:19PM -0400, Micah Nordland wrote:
> >> I believe this is what you are looking for:
> >>
> >> int xcb_get_file_descriptor (xcb_connection_t *c)
> >>   Access the file descriptor of the connection. ]
> >>
> >> Awesome WM currently uses this with glib, and in the past it used it with
> >> libev.
> >> bspwm uses this to do something similar to what you are doing.
> >> https://github.com/baskerville/bspwm
> > 
> > That does get a file descriptor referring to the X connection, but you
> > can't use that to wait for X responses without quite a bit of care,
> > because XCB might have some already read off the wire and stored in
> > internal buffers; thus, if you block on the X connection having data,
> > you might wait forever while XCB already has data to give you.
> 
> The following doesn't really help with Micah's issue directly, but it might make
> it possible to poll() the XCB fd for readability.
> 
> There is currently a patch[0] for Wayland "in the pipe" which makes something
> similar possible. The (simplified) idea there is that there are two functions
> wl_display_acquire_fd() and wl_display_release_fd(). When a thread has acquired
> the fd, no other thread may read from it.
> 
> This makes it relatively easy to integrate wayland into another main loop. In
> XCB-speak, before calling e.g. poll(), you would have to acquire the fd (and
> then check if there are any pending events?), call poll() and release the fd
> again afterwards.

That would effectively become an exposed XCB lock; with the fd
"acquired", no other thread could obtain events or replies, or for that
matter send requests.  That seems quite hazardous; we had quite a bit of
trouble with that back when it was called the "xlib" lock.

- Josh Triplett