Closed DusterTheFirst closed 4 months ago
I don't think nb
is that useful in practice because it doesn't allow composition of operations like futures do. If it doesn't even do that, it doesn't justify the extra layer of unwrapping you have to do to get to your data. In the future, when enough things are stable, I do dream about writing an async version of usb-device
and then we would have a reasonable way to do blocking-ish operations.
Additionally the way usb-device
is currently structured cannot reasonably accommodate blocking operations. Blocking in the nb
way while waiting for a class implementation to do something requires holding a reference to it while you're doing it, and the UsbDevice::poll
method (which has a somewhat strict timeout for calling it and cannot wait for your long blocking operation to complete) requires a &mut
to every class implementation you're using, which cannot co-exist with the reference you're using to block.
Closing this since there's no desire to migrate over. Additionally, nb
is largely deprecated nowadays for true async as it is.
The api of usb-device uses the
UsbError::WouldBlock
variant to signal that the current operation is waiting on the device. This is great for allowing non-blocking implementations of usb, but can be verbose to handle if the goal is to block on sending this data. The embedded HAL team has developed https://lib.rs/crates/nb which aims to standardize this behavior and comes with nice macros likeblock!()
which simplify working with apis that usenb
. Theusb-device
crate should adopt this standardized method to match what other crates in the embedded space do.