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

[Ben Hildred]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xcb/attachments/20150710/04cc2bed/attachment.html>