search for: io_compar

On Mon, 26 Feb 2018 23:01:29 +0100, Guus Sliepen wrote: > The problem is not the order of the events, the problem is that in the > Windows version of the event loop, we only handle one event in each loop > iteration. The select() loop handles all events that have accumulated so > far, so regardless of the order it handles them, it never starves fd. At > least, that was what I

...chance to proceed. But it doesn't order them by most recently accessed. It's a deterministic order that doesn't change except when io_add() or io_del() is called. Or put in another way: splay_each(io_t, io, &io_tree) goes through the nodes of the io_tree in the order determined by io_compare(). -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://www.tinc-vpn.org/...

...But it doesn't order them by most recently accessed. It's a > deterministic order that doesn't change except when io_add() or io_del() > is called. Or put in another way: splay_each(io_t, io, &io_tree) goes > through the nodes of the io_tree in the order determined by > io_compare(). Unlike the POSIX event code, the Windows version calls splay_search() to map the event to an io_t. The call to splay_search() will splay the tree which changes the order the next time we go through the loop. At least that's my take on it. It makes more sense to make the POSIX and Window...