device filtering support

[Vitali Lovich]

I'm going to have to side with Travis - spawning a secondary process seems unnecessary & wasteful.  Maybe if libusb applications were likely to run simultaneously with a lot of other libusb applications it might make sense (& even then not so much).  Is there really something wrong with caching the descriptors within the Windows backend, unless the driver already does it on our behalf (i.e. libusb0/libusbk)?  We can also throw away most of the cached information as soon as the device reference is released so there should be any significant long-term memory bloat.

-Vitali

On Feb 3, 2012, at 10:09 AM, Pete Batard wrote:

> On 2012.02.03 17:55, Travis wrote:
>> It is quite simple, take this common scenario:
>> 
>> 1) New libusb-1.0 single thread console application is launched.
>> (launches enumeration process)
>> 2) Application does some work and exits. (destroys enum process)
>> 
>> Your solution only adds the overhead of creating, using, and then
>> destroying the extra enumeration process.
>> 
>> Completely bat shit crazy!
> 
> Your mistake here is "extra".
> 
> We are not adding extra enum, we are moving the enum to a separate process.
> 
> So yes, it will create a new process, but well, it already creates a new thread for timer, and would need to create one for hotplug at least on Windows which we can move into the enum process, so difference = minimal
> Then this new process does an initial enum, _once and for all_ and when completed acknowledges a (potentially) delayed request for enum info for the original process from its libusbx_open() call. There's extra messaging involved, but so far not that different from what occurs with current libusb_open().
> Then the app uses that data, while our enum process sits very much idle and sleeping.
> Once done, the app call libusbx_exit() that destroys the enum process.
> 
> 
> But if you want bat shit crazy, let us consider this:
> 
> App opens and closes the same device repeatedly. Maybe it's been porrly written, maybe it's waiting on external events to communicate with USB, who knows...
> 
> Without the above solution, an enumeration list is build every time the device is opened, and this even if you filter the list (because you still need to do some filtered enumeration, and will still need to call SetupAPI or whatever on Windows). Do that a few hundred times, and tell me which one looks craziest.
> 
> Regards,
> 
> /Pete
> 
> 
> 
> _______________________________________________
> libusbx mailing list
> libusbx at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libusbx