Hi, Cool stuff, thanks! I believe this is best reviewed by Pete though, hopefully he can find some time for this in the not too distant feature.
Enjoy your vacation / away from the office time :) Regards, Hans On 06/27/2013 06:58 PM, Toby Gray wrote: > > I realise that 1.0.16 is currently trying to be released and that > these patches won't get looked at until after that has happened. I'm > away from the office for the next couple of weeks so thought it was > worth sending this patch series for people to look at if they get > time while I'm away. > > A while ago I mentioned that I thought that I was seeing performance > issues due to all the fake FD logic in the Windows backends. This patch > series makes these changes. > > This series is actually a group of related changes. > > Patches 1, 2 and 7 add some additional tests and testlib functionality. > > Patch 3 adds a new event API which provides FDs on POSIX systems but > HANDLES on Windows systems. > > Patch 4 changes the core code to make use of the new FD/HANDLE type. > > Patch 5 and 6 change the Windows backends over to using the FD/HANDLE type. > > While developing these patches I noticed that the Windows backends have a bug > where if you get more than MAXIMUM_WAIT_OBJECTS pollfds then any attempt at > a synchronous transfer will hang. The problem is that the handling of > events starts to fail when too many transfers have been submitted. This > is impossible to recover from as event handling needs to occur to remove > the pollfds for cancelled/completed transfers. > > Patches 8 and 9 modify the core code to allow pre-reserving of pollfds > and limiting the total number of concurrent pollfds. Instead of failing > in handling events with high numbers of pollfds this makes it possible > to fail the submission of the transfer. > > Patch 10 makes use of pre-reserving of pollfds in the Windows backends. > > Finally patch 11 enables limiting the number of concurrent pollfds on > Windows platforms. > > As for the original reason for this patch series, our actual > performance uses cases have improved by about 5% on WinCE through > these changes. > > Sadly the simple performance tests I created don't show any improvement > as they are limited by IO scheduling, not CPU usage. > > Regards, > > Toby > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > libusbx-devel mailing list > libusbx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libusbx-devel > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
