search for: event_loop

...tImpl() >= 0); } return NULL; } void callback(virConnectPtr conn, virDomainPtr dom, void *opaque) { // Do nothing. } void freecb(void *opaque) { // Do nothing. } int main() { assert(virInitialize() >= 0); assert(virEventRegisterDefaultImpl() >= 0); pthread_t event_loop; assert(pthread_create(&event_loop, NULL, loop, NULL) == 0); virConnectPtr conn = virConnectOpen("test:///default"); assert(conn != NULL); int cbid = virConnectDomainEventRegisterAny(conn, NULL, VIR_DOMAIN_EVENT_ID_LIFE...

On Tue, 27 Feb 2018 08:12:53 +0100, Guus Sliepen wrote: > I was thinking by setting a flag whenever we call io_del(), and checking > that flag in the for-loop in event_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 WSAWaitF...

...3 in receive_meta (c=c at entry=0x555555851be0) at meta.c:333 #4  0x00005555555603f9 in handle_meta_connection_data (c=c at entry=0x555555851be0) at net.c:304 #5  0x00005555555678c2 in handle_meta_io (data=0x555555851be0, flags=<optimized out>) at net_socket.c:520 #6  0x000055555555c60a in event_loop () at event.c:359 #7  0x00005555555607f2 in main_loop () at net.c:510 #8  0x0000555555559208 in main (argc=6, argv=<optimized out>) at tincd.c:558 (gdb) bt full #0  0x000055555556de41 in send_ans_key (to=to at entry=0x555555851060) at protocol_key.c:382         keylen = <optimized out&gt...

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

...ntry=0x555555851be0) at > meta.c:333 > #4  0x00005555555603f9 in handle_meta_connection_data > (c=c at entry=0x555555851be0) at net.c:304 > #5  0x00005555555678c2 in handle_meta_io (data=0x555555851be0, > flags=<optimized out>) at net_socket.c:520 > #6  0x000055555555c60a in event_loop () at event.c:359 > #7  0x00005555555607f2 in main_loop () at net.c:510 > #8  0x0000555555559208 in main (argc=6, argv=<optimized out>) at tincd.c:558 > (gdb) bt full > #0  0x000055555556de41 in send_ans_key (to=to at entry=0x555555851060) at > protocol_key.c:382 >        ...

...3 in receive_meta (c=c at entry=0x555555851be0) at meta.c:333 #4  0x00005555555603f9 in handle_meta_connection_data (c=c at entry=0x555555851be0) at net.c:304 #5  0x00005555555678c2 in handle_meta_io (data=0x555555851be0, flags=<optimized out>) at net_socket.c:520 #6  0x000055555555c60a in event_loop () at event.c:359 #7  0x00005555555607f2 in main_loop () at net.c:510 #8  0x0000555555559208 in main (argc=6, argv=<optimized out>) at tincd.c:558 (gdb) bt full #0  0x000055555556de41 in send_ans_key (to=to at entry=0x555555851060) at protocol_key.c:382         keylen = <optimized out&gt...

...ntry=0x555555851be0) at > meta.c:333 > #4  0x00005555555603f9 in handle_meta_connection_data > (c=c at entry=0x555555851be0) at net.c:304 > #5  0x00005555555678c2 in handle_meta_io (data=0x555555851be0, > flags=<optimized out>) at net_socket.c:520 > #6  0x000055555555c60a in event_loop () at event.c:359 > #7  0x00005555555607f2 in main_loop () at net.c:510 > #8  0x0000555555559208 in main (argc=6, argv=<optimized out>) at tincd.c:558 > (gdb) bt full > #0  0x000055555556de41 in send_ans_key (to=to at entry=0x555555851060) at > protocol_key.c:382 >        ...

...> detect that and only 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? 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 deterministi...

...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? - todd diff --git a/src/event.c b/src/event.c index 33d205a..b60a6d7 100644 --- a/src/event.c +++ b/src/event.c @@ -387,71 +389,89 @@ bool event_loop(void) { Note that technically FD_CLOSE has the same problem, but it's okay because user code does not rely on this event being fired again if ignored. */ - io_t *writeable_io = NULL; + unsigned int curgen = io_tree.generation; - for splay_each(io_t, io, &io_tree) + for...

...no longer reproduce the problem of nodes not responding to pings. Another solution would to randomly shuffle events[] but that seems needlessly complicated. - todd diff --git a/src/event.c b/src/event.c index 331872a..03111d0 100644 --- a/src/event.c +++ b/src/event.c @@ -403,11 +403,14 @@ bool event_loop(void) { } WSAEVENT *events = xmalloc(event_count * sizeof(*events)); - DWORD event_index = 0; + DWORD event_index = event_count; + /* + * Fill events[] in reverse order. Otherwise we may starve + * events other than the TAP, which is usually at the head. + */ for splay_each(i...

(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