device filtering support

[Pete Batard]

On 2012.02.04 21:28, Michael Plante wrote:
> Pete Batard wrote:
>>> I'm both trying to optimize and avoid potentially disruptive traffic.
>
> Please define disruptive.  If you just mean "excessive", then I would say
> that's redundant (just optimization) and we should just go with threads.  If
> you mean "it breaks things", then I'd say we need to rethink this whole
> thing.  Did I miss a third potential meaning for "disruptive"?

OK. Disruptive, in the way I understand Travis' concern, is:
- libusbx (or non libusbx) app 1 is doing isochronous or bandwidth heavy 
transfers on the bus
- libusbx app 2 is either launched or does something (open) that 
produces an enum. With the current Windows enum process, this results in 
hubs being queried and potential packet dropped for app 1.

Could also be a multithreaded app, instead of 2 separate ones.

This is how I have been conceiving the disruption concern so far.

> Let's ignore for a moment that this is now highly platform-dependent (an
> issue that could go away with [p]threads)

Using pipes for messaging seems to be pretty universal, and there are 
probably other close-to-universal ways.

> and let's focus on Windows.
> Presumably this data is passed around with shared memory?

Not necessarily. I do not see much data needing to be transferred, so a 
pipe would probably do. That's what I use in libdwi, to send data back 
and forth as well as logging data, between 2 processes (the driver 
installer process, and the libwdi based app itself).
Like you, I'd rather avoid using shared memory.

> Ok, you can make
> it read-only.  Some sort of locking may still be required to prevent the
> data from being updated while the client process is still reading it, and
> then that client process may hold that lock longer than it should.  I'll
> grant this is not as bad as I made it sound, but it is still an annoyance
> that will lead to the libusbx process living longer than it should for what
> appears to the user to be no obvious reason, giving libusbx a bad name, at
> least to anyone who knows just enough to open task manager.

The way I see the libusbx process should live for as long ad possible. 
It's not exactly a daemon or a service, but it's pretty darn close in my 
book. If we were to go with such an implementation, I'm actually 
wondering if I'd want to kill the process at all on the last 
libusbx_exit, because there would be some benefits in not doing so...

> I still would prefer a threaded implementation.  It's cleaner.

Yes, I agree, it's less trouble to implement. But this still means that 
something we should ideally do only once (enumerate libusbx devices - 
then update as needed on account of hotplug) may get duplicated, and on 
Windows, that potentially disruptive queries may occur each time it is.

>>> But is it nightmarishly complex?
>
> I exaggerated slightly, but my position stands.

And I'm not going to pretend it'd be a walk in the park, even with cross 
platform pipe mechanisms. However, I do see a lot of "I've done this 
before, and can quickly lift some code up" in there, as I have something 
very similar in libwdi.
Granted, it was only for Windows, but nothing I used seemed very 
platform specific, at least in terms of expecting other platforms not to 
have equivalent calls.
And please understand that I'm not trying to shove libwdi features down 
libusbx's throat or pretend that there's "one true way" to do it. It's 
just that I've done something quite similar to what I think we could use 
to solve the problem of providing a centralized libusbx enum as well as 
hotplug support, should we decide that it's an issue we want to solve.

If I hadn't done something similar before, I'd probably be a lot more 
cautious...

Regards,

/Pete