Possible to do a ControlOut request with a timeout

[andrewdavidmackenzie]

Great crate, easy to use, thanks for that!

I'm using nusb from my Iced application, and using all the async methods.
Is it possible to do an Interface::control_out() call, but with a timeout?
If not, I guess I will find a way to cancel the future after some time, but as I saw it on control_out_blocked() I thought I'd ask.
thanks

[martinling]

Issue #4 is open for this feature, but it would currently require either the futures_lite crate to add a timeout API, or nusb to gain additional dependencies.

[andrewdavidmackenzie]

Thanks. Although the issue title is a bit misleading no? It would be "timeouts for async/non-blocking IO" no? I guess I'll implement the "race", using select I guess?

…

On Fri, Nov 15, 2024, 1:26 AM Martin Ling ***@***.***> wrote: Issue #4 <#4> is open for this feature, but it would currently require either the futures_lite crate to add a timeout API, or nusb to gain additional dependencies. — Reply to this email directly, view it on GitHub <#91 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKF4LA5RFFMCIZFBPWK3FT2AU5TVAVCNFSM6AAAAABRZKCPICVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRWGEZDGNY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kevinmehall]

Yes, select or race with an async_io::Timer, or tokio::time::timeout are the way to go there. You need a more full-fledged async runtime to give a future a timeout.

[martinling]

Yeah the title is misleading at this point I guess.

For some context, when that issue was opened, the control_in_blocking and control_out_blocking methods hadn't been added yet.

But those timeouts aren't really integrated into the async side of things - those methods just use the synchronous APIs on the OS. And those methods are only available for control transfers.

So having a block_on with a timeout, or a TransferFuture with a built-in timeout, would still be really useful.

[kevinmehall]

The proposal in #4 is to integrate the block_on mini-executor and implement the timeout there when blocking until a completion event. That's easier to do than making the Future itself time out because the underlying CondVar used for waiting already implements a timeout, so you basically use the blocked thread as the timer.

The 3 operating systems support timeouts for transfers in different ways, making it hard to abstract over any underlying OS functionality at the USB level:

• macOS supports async transfer timeouts natively.
• Windows has a timeout that is set per-endpoint, not per-transfer.
• Linux has no timeout support in its async APIs and expect you to just cancel the transfer after your own timeout.

To make the Future itself time out without the cooperation of the executor or OS-level USB API is trickier and would probably require depending on async_io::Timer or Tokio to have a background thread emitting timer events. That's essentially the same as what you can do externally with a timer implementation of your choice and select.

It seems that typically Rust async IO futures such as those provided by tokio and async_io don't time out on their own, and expect you to race with a timer future, or use a convenience wrapper that does that for you.

A user of a blocking API can't implement a timeout externally, and may not be familiar with the async ecosystem to do it themselves, so it seems like something the library should provide there, but I'm not sure it belongs in nusb's async APIs for those reasons.