[Xcb] Feature Request: Function "xcb_test_for_event"

[Bart Massey]

"Currently, Qt5 spawns a thread which just sits in xcb_wait_for_event() so
that X11 events can get handled properly." This is sort of the intended way
to use XCB for a program in which multiple threads touch the X connection.
XCB supplies events in the simplest possible way, and applications can wrap
whatever higher-level semantics they want. It seems to me pretty
straightforward to implement the acquire/release semantics via thread IPC...

I guess the issue is, as usual, interactions between library threads from
different libraries, and interactions between library and client threads.
Probably somebody needs to architect a convention for threads sharing an X
connection, and then either modify XCB or layer on top of it to enforce
this. I can think a little about what that might look like...

--Bart


On Wed, Apr 10, 2013 at 9:38 AM, Uli Schlachter <psychon at znc.in> 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.
>
> I am not 100% sure that the above description would really work for
> toolkits
> (can they really handle new events coming in while preparing for poll()?),
> but
> if would be great if something like this were implemented. Currently, Qt5
> spawns
> a thread which just sits in xcb_wait_for_event() so that X11 events can get
> handled properly.
>
> Cheers,
> Uli
>
> [0]:
> http://lists.freedesktop.org/archives/wayland-devel/2013-April/008569.html
> --
> If you have to type the letters "A-E-S" into your source code, you're
> doing it
> wrong.
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20130410/9377dd6f/attachment.html>