search for: wsawaitformultipleevents

...renegotiate. My theory is that, due to the properties of the splay tree, the TAP device event is almost always at the head of the tree and thus if there is traffic, that event will be serviced at the expense of meta communication. Because splay_search() is used to find the first event returned by WSAWaitForMultipleEvents(), the next time through the loop the last event serviced will be the first in the events[] array. This doesn't happen with the select() version of the event loop. It is possible to eliminate the splay_search() by using an extra array to hold io_t pointers but I've had better results just...

...exit the loop early if that's really the case. I'll > do that. How would you detect that? By checking whether the next node has changed? > For Windows, there are two issues that have to be fixed. First is > that we only handle a single writable IO event. The second is that > WSAWaitForMultipleEvents() only returns one index into the array of > events, even though multiple events might have triggered. How hard would > it be to check for all triggered events? I don't think it is too hard. I was working in that direction initially but wasn't sure if a larger change would be welcom...

Here's a diff to call WSAWaitForMultipleEvents() repeatedly to check for events other than the first one returned. I've also added a map of io_t to events[] index so avoid the need for splay_search(). The value of event_count will change if a callback adds an event so we need to handle that. I've added a generation number to the splay...

...t, due to the properties of the splay tree, the TAP > device event is almost always at the head of the tree and thus if > there is traffic, that event will be serviced at the expense of > meta communication. > > Because splay_search() is used to find the first event returned by > WSAWaitForMultipleEvents(), the next time through the loop the last > event serviced will be the first in the events[] array. This doesn't > happen with the select() version of the event loop. > > It is possible to eliminate the splay_search() by using an extra > array to hold io_t pointers but I'v...

...> > How would you detect that? By checking whether the next node has > changed? I was thinking by setting a flag whenever we call io_del(), and checking that flag in the for-loop in event_loop(). > Changing the order of the events changes the index of which event > is returned by WSAWaitForMultipleEvents(). Moving the most recently > accessed event to the end gives the others a 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,...

...ent_loop(). So basically you would store a generation number in the tree that gets incremented by a call to io_del()? Or should the flag/number be changed each time the order of the tree changes? > > Changing the order of the events changes the index of which event > > is returned by WSAWaitForMultipleEvents(). Moving the most recently > > accessed event to the end gives the others a 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 wa...

On Tue, Feb 27, 2018 at 11:23:54AM -0700, Todd C. Miller wrote: > Here's a diff to call WSAWaitForMultipleEvents() repeatedly to check > for events other than the first one returned. I've also added a > map of io_t to events[] index so avoid the need for splay_search(). That's great, less changes to the tree are good. > The value of event_count will change if a callback adds an event >...