futures-rs

https://github.com/rxRust/rxRust Many Rust projects are blah-rs where the rs is dropped in the crate name. So it would be normal to be confused and think Rx == RxRust. e.g. https://github.com/rust-lang/futures-rs has crate name "futures". >There's not that many good, short names. There'd be loads if the Rust community (or.. the 'rust parliamentary community' (people who actually get involved in the RFC processes and see things through to the end (heroes, imo)) (cf PLP[0])) elected to use namespaces for crates. [0] https://en.wikipedia.org/wiki/Parliamentary_Labour_Party

Ah, all the helpers around the "FSM" aspect of things are already exposed as part of the `futures` crate: https://github.com/rust-lang-nursery/futures-rs/

It will be interesting to see whether Rusts async ecosystem gets support for it. However there is a little bit of a challenge in the form of an impedance mismatch: Rust Futures and thereby also async functions require that an operation is cancellable at any point of time (by dropping the respective Future). IO completion based systems (like io_uring and IOCP) typically don't support this. If the operation in the Rust userspace would be cancelled while the Kernel proceeds with the operation the Kernel would act on invalid memory. There are some workarounds for this, like wrapping the APIs in ones that only used owned buffers that are passed for the whole duration of the operation and reference-counting the IO objects (file descriptors). But the behavior is pretty tricky. [1] describes the problem. [1] https://github.com/rust-lang-nursery/f