search for: io_t

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...

...e 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, &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...

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

...e 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 filling the events[] array in reverse order. This results in the most recently serviced event being added to the end of events[], which should prevent one very busy event from monopolizing the event loop. With this change I can no longer reproduce the...

...ipleEvents(). 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, &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: a...

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 > in...

...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 filling > the events[] array in reverse order. This results in the most > recently serviced event being added to the end of events[], which > should prevent one very busy event from monopolizing the event loop. The problem is not the order of...

...ning: SystemIO range 0x0000000000000800-0x000000000000082F conflicts with OpRegion 0x0000000000000810-0x0000000000000813 (\IO_D) (20160930/utaddress-247) [ 8.598312] ACPI Warning: SystemIO range 0x0000000000000800-0x000000000000082F conflicts with OpRegion 0x0000000000000800-0x000000000000080F (\IO_T) (20160930/utaddress-247) [ 8.598316] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver [ 8.598317] lpc_ich: Resource conflict(s) found affecting gpio_ich [ 8.612890] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt [ 8.644920] (NULL...

...L07.p. \ 4f90: 2f 04 5f 53 42 5f 50 43 49 30 53 42 55 53 48 53 /._SB_PCI0SBUSHS 4fa0: 54 53 14 15 5f 4c 31 45 00 86 5c 2e 5f 53 42 5f TS.._L1E..\._SB_ 4fb0: 50 57 52 42 0a 02 a4 00 10 40 29 5c 00 5b 80 49 PWRB.....@)\.[.I 4fc0: 4f 5f 54 01 0b 00 10 0a 10 5b 81 24 49 4f 5f 54 O_T......[.$IO_T 4fd0: 01 54 52 50 49 10 00 10 00 10 00 10 54 52 50 30 .TRPI.......TRP0 4fe0: 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 5b ...............[ 4ff0: 80 49 4f 5f 44 01 0b 10 08 0a 04 5b 81 0b 49 4f .IO_D......[..IO 5000: 5f 44 01 54 52 50 44 08 5b 80 49 4f 5f 48 01 0b _D.TRPD.[.IO_H.. 5...