Hi, On 04/11/2013 05:20 PM, Toby Gray wrote: > Hi, > > We've been looking into the performance of the Windows desktop and Windows CE > versions of libusbx compared to Linux on the same hardware. The event > handling in Windows and Windows CE appears to take considerably longer than > for Linux. > > This is understandable given the way that the windows backends need to > pretend to have fds for the core of libusbx to process. > > Rather than trying to optimise how the fake fds are generated and handled, I > think the best thing to do is to add improved APIs to improve event handling > on platforms which don't have fds and then change the internals to not need > fake fds. > > Before I rush off an implement something, I wanted to check with the > community to see how people feel things should be done. > > I see two possible ways of approaching the problem: > > 1) Add a new type, libusb_event_handle, which either maps to an FD or a > HANDLE, as appropriate on each platform. I've attached a first attempt at the > API changes in new_event_api.diff. It is a new API but is very similar to the > pre-existing poll api. > > 2) Add the ability to start and stop async event processing threads which are > internal to libusb. I've attached a first attempt at the API changes in > async_thread_api.diff. > > I think the second approach probably matches up better with the future > direction of hotplug. The only benefit I can really think of the former > approach is that it allows the libusbx user to continue to control the thread > context for transfer completion callbacks, as well as when the callbacks can > occur.
I don't want to come over to negative here, but I'm strongly against method 2. Many applications and frameworks still follow the model of having a single main event loop. 1) fits this very nicely where as 2) does not at all. 2) Can be easily offered on top of 1 by having a start / stop event handling functions, which start a thread and then fire of callbacks from that thread for API users who don't mind dealing with threading issues, and don't want to be bothered with calling some wait-for-events function themselves. As for 2 matching with hotplug, the latest (not saying it is the best, but it is the most concrete code we've atm) hotplug code in the libusb-1.0.16 rc-s has been changed to no longer fire hotplug events from $random-thread, instead they are now fired from which ever thread calls libusb_handle_events*, and there is an fd to poll to figure out when calling libusb_handle_events* for hotplug is necessary. So the libusb-1.0.16rc hotplug code currently behaves much more like 1) then like 2) Also as Pete said, lets not spend too much time talking about this, just show us the code :). Preferably code modeled after method 1). Regards, Hans ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
