Hi, On 05/27/2013 04:54 PM, Sean McBride wrote: > On Fri, 24 May 2013 17:22:19 -0600, Nathan Hjelm said: > >>> My app only communicates with one particular USB device, and I don't >> much like the idea of my process running code whenever the user happens >> to plug in a keyboard, mouse, USB key, or other unrelated thing. >> >> The code that is running is no different that what libudev or the os >> runs every time a device is plugged in. I doubt you would notice the < >> 1500 us time it takes to enumerate a device on darwin. > > My concern is not the execution time. My concern is stability and QA. There > have been race conditions in libusb in the past (all software is buggy, > that's not a jab). I really don't want to see weirdo crashes because > customer X plugged in device Y, which I was never able to test for. Being > able to just opt in/out of the hotplugging code would make my QA burden > easier, especially if the code is multithreaded, which of course is even > harder to test well.
The problem with adding an opt-out, is that we then also need to keep the old static scan all current devices code arround, which means 2 enumeration paths to maintain and QA, not a very good idea IMHO. The new hotplug code looks pretty solid, and is no where as fragile and complicated as the whole completion + timeout handling code, where indeed we've had issues in the past. I'm not saying it is bug-free, but I do believe our efforts are best spend trying to make one enumeration path work well, rather then having 2. Regards, Hans ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
