device filtering support

[Pete Batard]

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