<div dir="ltr"><br clear="all"><div>First off the description of xcb_get_file_descriptor at <a href="http://xcb.freedesktop.org/PublicApi/#index8h2">http://xcb.freedesktop.org/PublicApi/#index8h2</a> 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.</div><div><br></div><div>From <a href="http://lists.freedesktop.org/archives/xcb/2013-April/008224.html">http://lists.freedesktop.org/archives/xcb/2013-April/008224.html</a></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>On Mon, Apr 08, 2013 at 07:52:19PM -0400, Micah Nordland wrote:</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>></span><i style="color:rgb(0,0,0);white-space:pre-wrap"> I believe this is what you are looking for:</i></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>></span><i style="color:rgb(0,0,0);white-space:pre-wrap"> </i></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>></span><i style="color:rgb(0,0,0);white-space:pre-wrap"> int xcb_get_file_descriptor (xcb_connection_t *c)</i></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>></span><i style="color:rgb(0,0,0);white-space:pre-wrap">   Access the file descriptor of the connection. ]</i></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>That does get a file descriptor referring to the X connection, but you</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>can't use that to wait for X responses without quite a bit of care,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>because XCB might have some already read off the wire and stored in</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>internal buffers; thus, if you block on the X connection having data,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>you might wait forever while XCB already has data to give you.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">>- Josh Triplett</span><br></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><div>From <a href="http://lists.freedesktop.org/archives/xcb/2006-August/001847.html">http://lists.freedesktop.org/archives/xcb/2006-August/001847.html</a></div><div>>The problem with select()ing on the XCB FD is that I'm</div><div>>pretty sure you can get into races with XCB in a</div><div>>multithreaded situation, and even in a single-threaded</div><div>>situation you may experience false wakeups from reply data.</div><div>>If you select(), then XCBPollForEvent() until no more events</div><div>>are available whenever the XCB FD shows readable, it will</div><div>>*probably* work, but I'm a little confused about races</div><div>>between calling XCBPollForEvent(), live data arriving, and</div><div>>falling back into the select().  Even if it works, I'm not</div><div>>convinced that we want to *guarantee* that it will work...</div><div>></div><div>>It seems clear from folks' comments that XCB core or at</div><div>>least Util needs to support some better I/O-multiplexing</div><div>>mechanism for event-driven single-threaded programs.  Some</div><div>>of us will chat offline about this RSN, and hopefully there</div><div>>will also be an online conversation about what it should</div><div>>be.  Good ideas appreciated.</div><div>></div><div><span class="" style="white-space:pre">>        </span>Bart</div></div><div><br></div><div>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?</div><div>--</div><div class="gmail_signature"><div>--</div><div><div>Ben Hildred</div><div>Automation Support Services</div></div><div>303 815 6721</div></div>
</div>