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

[Bart Massey]

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'm pretty sure the concerns expressed about the single-threaded
case in my email were unfounded.

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


I think. Somebody correct me if I'm wrong.

On Fri, Jul 10, 2015, 17:54 Ben Hildred <42656e at gmail.com> wrote:

>
> First off the description of xcb_get_file_descriptor at
> http://xcb.freedesktop.org/PublicApi/#index8h2 gives the definate
> impression that it is only valid to call when you already know the result.
> I t would be useful to clarify if that is indeed the case or if it will
> work with any connect function which would make more sense. So while
> researching that (to no good answer) I came across some disturbing comments.
>
> From http://lists.freedesktop.org/archives/xcb/2013-April/008224.html
> >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. ]*
> >
> >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.
> >
> >- Josh Triplett
>
> From http://lists.freedesktop.org/archives/xcb/2006-August/001847.html
> >The problem with select()ing on the XCB FD is that I'm
> >pretty sure you can get into races with XCB in a
> >multithreaded situation, and even in a single-threaded
> >situation you may experience false wakeups from reply data.
> >If you select(), then XCBPollForEvent() until no more events
> >are available whenever the XCB FD shows readable, it will
> >*probably* work, but I'm a little confused about races
> >between calling XCBPollForEvent(), live data arriving, and
> >falling back into the select().  Even if it works, I'm not
> >convinced that we want to *guarantee* that it will work...
> >
> >It seems clear from folks' comments that XCB core or at
> >least Util needs to support some better I/O-multiplexing
> >mechanism for event-driven single-threaded programs.  Some
> >of us will chat offline about this RSN, and hopefully there
> >will also be an online conversation about what it should
> >be.  Good ideas appreciated.
> >
> > Bart
>
> Now at this point I am quite concerned as I was planning on using select
> to monitor three file descriptors in a seyon like program (one of which is
> the X server) and since this is a practice program before implementing an
> XCB binding into unthreaded language that relies heavily on select for
> event loops. My plan was to use a double level event loop. The outer level
> uses select to wait for input on multiple filehandles. the inner loop
> (actually one per file handle) would read from each filehandle until a read
> did not return a complete event. Why would there be any concern about race
> conditions?
> --
> --
> Ben Hildred
> Automation Support Services
> 303 815 6721
>  _______________________________________________
> 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/20150712/8b403b13/attachment.html>