On 2013.04.11 16:20, Toby Gray wrote: > 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.
Oh boy, here we go again... > Before I rush off an implement something, I wanted to check with the > community to see how people feel things should be done. If that's the case, then you may want to check 3 years of libusb mailing list archives as well as one year of libusbx, because this topic has probably been discussed about once every 3 months on each list. I think the plan on which we more or less agreed for libusbx was that we would wait until _AFTER_ we had an initial hotplug implementation for all of Linux, OS X and Windows, to look into improved event handling. The reason is it'd be nice if the hotplug event handling could fit with the transfer event handling, but until we see clearer in terms of hotplug, whatever we _think_ we need in terms of event handling may end up being way off mark. Also see the current v2.3 libusbx milestone: https://github.com/libusbx/libusbx/issues/milestones IMO this is still way off on the horizon, and isn't something we should be looking at right now, especially not in the 1.x branch. > 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. Have a look at the libusb archives, with some of the conversations involving Michael Plante, Orin Eman and others on the subject. > I think the second approach probably matches up better with the future > direction of hotplug. A future direction that, as far as I'm concerned, is still ill defined. > Any thoughts or alternative suggestions are welcome. OK, then let me be very frank here (with an opinion that'll probably not reflect the one from other libusbx maintainers): I'm getting kind of tired of people proposing yet another API, without any details of how it's actually going to be implemented for each of our 3 major platforms (Linux + OS X + Windows). And yeah, I know RFC and whatnot may sound like the way to go, but proposing an API _is_ cheap, and, judging from our mailing list history, seems to be a sure way to generate a lot of discussion that ends up nowhere or worse, that detracts people from what our real number one need which is: code, code, and more code. We've had a lot of API proposals over the year, some of which failed miserably at the first concrete implementation hurdle (i18n libusb_strerror() anyone?), and some of which never took off despite somewhat universal agreement, due to lack of developers willing/able to invest development time in an implementation (there was a good example of that, I think in late 2011, but what it was about completely eludes me right now). So every time someone comes along, and goes "hey I've got this cool idea for a new libusb/libusbx API", I can't help but be dubious about who's going to be doing the _real_ work of implementing it, for the 3 main platforms, and who, given the constraints we have in each environment, might be the one to point out that we may not have been as smart as we thought we were, in terms of foreplanning. The thing is, we really don't have any constraints right now. We'll launch the experimental libusbx 2.x branch soon, where we can introduce tentative APIs as we go along and remodel them until we're satisfied. Why then should we want to put ourselves on a leash, when we can roam freely for a while and define our own preferred path as a result, in due time. So if it were up to me, I'd try to concretely find out what we really need (which, unfortunately, requires a somewhat working Windows hotplug implementation) before trying to introduce improved event handling... Regards, /Pete ------------------------------------------------------------------------------ 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
