Remove USE_POLL

[thegecko]

Changes

• In preparation for making this addon context aware, plan to drop some complexity as I'm not aware this is used any longer.

Checklist

Have you...

• Tested the change acts as expected
• Checked the change doesn't remove or change existing functionality
• Considered how the feature impacts the product and tested around it (not just the happy paths)
• Where possible, executed the hardware tests on multiple operating systems

[mildsunrise]

it's a bit sad that due to one platform (Windows) we'll need an additional thread + completion queue on platforms that support efficient integration with the event loop... but hotplug isn't a very critical functionality so I'm good with dropping efficiency if it reduces complexity.

[thegecko]

To be honest, it wasn't clear to me what this did, but as it's currently ignored at build time it seemed like an unnecessary overhead to maintain.

What is it on Windows which isn't supported?

[kevinmehall]

On Unix, libusb can return a set of file descriptors that can be polled for events by Node's own libuv event loop. This isn't supported on Windows, so the cross-platform way is to run a thread that loops on libusb's blocking libusb_handle_events and have the callbacks on that thread wake the Node event loop. This is for transfer completion events too, not just hotplug.

Looks like I had it briefly turned on for Linux / Mac in 2013 and then reverted due to issues I never got around to debugging. Removing is probably the right call.

[thegecko]

Thanks for the detail @kevinmehall

[mildsunrise]

ah true, I forgot this was also for real USB I/O as well...

hmm, in that case I'd like to implement it someday, for I/O heavy apps I believe the extra efficieny is worth the added complexity (and the theoretical consequence for ABI stability is much more lax in practice).