Nick Cameron
Nick Cameron
> Shouldn't AsyncRead and AsyncReady be renamed Read and Ready in the "Complete version" code block ? Whoops! They absolutely should. Fixed now, thanks!
Feedback from Fuchsia: > The proposal suggests that for optimal performance, Ready should be used followed by a read call later. I think that might be quite challenging for us...
Some discussion on a possible alternative where we have a type like smol's `Async` and some of the API is on that type rather than the io traits (I believe...
The `read_with` style helpers from smol::Async may also be helpful for making the memory-optimal path more ergonomic in some cases.
I've started to write up the designs from the blog posts in https://github.com/nrc/portable-interoperable/tree/master/io-traits
exactly the same way as the macro_rules version, but you will need to enable a feature (`proc_macro_hygiene` or something similar) and import the macro. Would be good to document this,...
I feel like `with` is important for some issues, but orthogonal to others. Obviously `with` clauses would affect how executors are passed around and interacted with, but they seem mostly...
Join macro is now in core (unstable): https://github.com/rust-lang/rust/pull/91645
Some thoughts from initial investigations: The key difference between `non_blocking_read` and `async read` is about intentions and invariants: if `non_blocking_read` would block then that is probably due to the data...
Completion based IO is likely to use BufRead or OwnedRead or similar, rather than these functions