Plans/roadmap

[achan1989]

Hi, it's nice to see someone having a go at a Rust-y version of the new libusb API :)

Do you have particular goals or features that you want to add? I wouldn't mind helping with the asynchronous API if that's something you plan to do (although I've never done something like that before, so I don't know how much I can contribute).

[a1ien]

Hi. I want add async but a safe implementation can be complicated. More info
rust-lang/futures-rs#1278

[achan1989]

Ok. I see that you recently removed an async implementation. What didn't you like about it?

[a1ien]

1. It's not idiomatic async code
2. it's wait when transfer complete in drop. Which is not good

[harrychin]

It looks like async destructors are on the Rust team's radar which would definitely help.

https://boats.gitlab.io/blog/post/poll-drop/

[flukejones]

Why was this dropped? This is purely for usb async transfer, nothing to do with rust async.

Form what I've learned the purpose of this is to enable libusb to have multiple packets qued up so that when one packet transfer is completed, the next can begin in the same frame. So when one frame takes 1ms regardless of what you do, this libusb specific async transfer will be extremely handy.

It doesn't need to have rust async, it's perfectly fine to sync wait on this as libusb is still doing an async transfer. Then when someone else does want to use rust async, they can wrap it.

[a1ien]

It's droped because it's not safe wrapper. https://www.reddit.com/r/rust/comments/cadbkm/what_is_the_current_status_of_async_usb_in_rust/et8h96y/

[flukejones]

I understand now that I tried using it 🤣. Very sorry if I've come off as pushy, I've spent a few weeks on this project now.

[tarcieri]

In absence of a safe solution asynchronous Tranfser dropping (and I'm guessing other issues), I'm wondering if it'd make sense to have a stopgap for better integrating rusb into async environments, even if that solution is a sort of channel-based service that runs rusb synchronous operations in a background service worker thread.

I suppose that's the sort of solution which could be developed in a 3rd party crate, but it seems like it'd be nice to have a common solution to this problem.

(also small suggestion: perhaps rename this issue to something like "Async support" since it seems like that's all that's being discussed here)

[SnowyCoder]

If I understood the old implementation the asynchronous drop is not a problem since Transfer is only present when a request is not submitted. The bug about forgetting the AsyncGroup could be resolved with a minimal rewrite by making Transfer allocate it's own buffer (so if forget is called the buffer will not be available for reading/writing).

It's not a perfect solution and it adds a bit of performance overhead since each Transfer will need to allocate its own buffer, but I think that it's better than no solution at all.

[a1ien]

@SnowyCoder Yes it's might work. Also we can look at ringbahn. And take some ideas from them. I do not promise that I will implement it quickly, but I think to take a look. Also I will gladly accept PR for this