search for: splay_search

...gt; 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 Windows versions be as close as possible so I've abandoned this approach....

...ns, the sender closes the connection and both ends have to 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...

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 tree head that gets incremented by io_del(). I'm undecided whether it should also be incremented by io_add(). Does this seem like the right direction...

...both ends > have to 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 s...

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

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 > so we need to handle that. > > I've added a generation number to the splay tree head that gets > incremented by io_del(). I'm undecided whether it...

(Second try to send this. I wonder if the first one gotten eaten by a spam filter; I'll link to patches instead of attaching them.) Here are the tincctl patches I've been working on. They apply to http://www.tinc-vpn.org/svn/tinc/branches/1.1@1545. I intend to commit them once the crypto stuff's fixed. Since they're basically done, I'm emailing them now for review and in case