On Jan 30, 2008 7:03 AM, Vincent Torri <[EMAIL PROTECTED]> wrote: > > hey > > here is a more detailed explanation of Jamey about the race condition that > can occur with xcb_poll_for_reply. You know those things better than me, > so you will be able to comment about that on the race in ecore in the ML > > Vincent
Thanks for following up with them. > On Mon, Jan 28, 2008 at 11:09:53PM +0100, Vincent Torri wrote: > > Huh, sure enough. That code looks about right. I think you'll want to > > make the "buf_func" always return 1, though. XCB has no direct > > equivalent to the XPending call that ecore_x uses there, but > > xcb_poll_for_(event|reply) is just as efficient as XPending, so you > > should just run the full scan for pending items. I think the same > > argument pretty clearly applies to ecore_x on Xlib, for that matter... This sounds like what we discussed. > The issue to worry about here is not a "race" in the classical sense, > > but it has about the same result. When you send a request, XCB (like > > Xlib) may read some unrelated response off the wire. Then when you get > > around to your select() call, there's nothing on the wire to read, so > > you block--but you could have made progress by polling XCB's queues. In > > the worst case, this leads to your application hanging, so it can also > > resemble a deadlock. Doesn't XCB use non-blocking file descriptors? This should only be a problem if they only handle blocking file descriptors within XCB, otherwise the read should return immediately with a zero length result. We have yet to run into this issue with Xlib, so it may be a case we already handle in the ecore main loop or ecore_x. > No kidding. Official position: we don't encourage this, but have fun. > > kthxbye. :-) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
