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
On Mon, Jan 28, 2008 at 11:09:53PM +0100, Vincent Torri wrote: > On Mon, 28 Jan 2008, Jamey Sharp wrote: >> As Bart pointed out earlier, if you do this without an extra thread, you >> need to be very careful not to spin. xcb_poll_for_reply, like >> xcb_poll_for_event, will not block when there is no input. If you don't >> have any other work to do, you need some other way to block so you don't >> waste all your CPU time. If you're very careful, you can do that with >> select(2) or poll(2) on the file descriptor of the socket connected to >> the X server, but there are subtle traps there too. > > raster already does that stuff for X events and xcb_poll_for_event (well, i > wrote that xcb part, actually). We indeed do a select on the fd. 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... On Mon, Jan 28, 2008 at 02:37:44PM -0800, Barton C Massey wrote: > These races with the external world / OS may occur even in > single-threaded programs. I can't come up with an easy > example offhand, and there may not be any. 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. > I'm just saying you'll have to think about it carefully, > because this sort of usage of XCB was not well thought out > or tested. No kidding. Official position: we don't encourage this, but have fun. kthxbye. :-) Jamey
signature.asc
Description: Digital signature
_______________________________________________ Xcb mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xcb
------------------------------------------------------------------------- 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
