On 07/09/11 06:05, Ben Greear wrote: > In the win_dispatcher.cc, it is calling WaitForMultipleObjects. The > existing code that works OK just uses the retval - WAIT_OBJECT_0 object. > But, if I read the MS help pages right, that is really just the first > entry that may have events pending, and one should probably check the > rest to make sure we are not starving higher objects.
I have a portable event reactor which I last looked at some time ago, so this is all IIRC. For Windows, I used WaitFor* functions, and I think I managed to get some successful behaviour out of it, for a moderate task (a TCP proxy). However, I probably relied on wine, or simply passing the tests over to someone routinely using Windows, so it can't have been as rigorous as the testing and practical use it's had on Linux. Looking at the code now, it seems I've called WaitForMultipleObjects several times, with almost the same array. The return code evidently identifies one of the entries that has fired (the first one), but I needed to ensure that all the other ones were queued before actually executing any of them, so they could be executed according to user-defined priorities. So, I believe the code removes the identified event from the array, and re-calls WaitFor* to pick out the next one. Re-calls always use a zero timeout, since an event has already fired. IOW, having detected one event, WaitFor* is used repeatedly to enumerate all the others, so you get the same effect as a single select() with scan over the fd_sets. If you'll excuse the self-signed cert, you should be able to see the code here: <https://forge.comp.lancs.ac.uk/svn-repos/utils/react/trunk/yield.c> Cheers, Steven _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
