How I want to simplify async filesystem APIs... 1/13
-
-
First, take a look at the filesystem APIs in async-std and tokio: 2/13 https://docs.rs/async-std/1.5.0/async_std/fs/index.html … https://docs.rs/tokio/0.2.13/tokio/fs/index.html …pic.twitter.com/KqHynp6smb
1 reply 0 retweets 1 likeShow this thread -
Both async-std and tokio are reimplementing the whole std::fs in an async manner. But can we invent some kind of async adapter for std::fs instead of replacing it entirely? 3/13
1 reply 0 retweets 1 likeShow this thread -
Consider a function like tokio::fs::read_to_string(). Do we really need it? 4/13 https://docs.rs/tokio/0.2.13/tokio/fs/fn.read_to_string.html …pic.twitter.com/8X85P1j2D5
1 reply 0 retweets 0 likesShow this thread -
Imagine there was a blocking!() macro that offloads a piece of code onto the blocking pool, kind of like spawn_blocking() with a nicer syntax. Then we could simply use std::fs::read_to_string() inside this macro. 5/13pic.twitter.com/GTjnEdHXrq
1 reply 0 retweets 0 likesShow this thread -
That's actually not too bad! If we have the blocking!() macro, we don't really need async versions of any of the standalone functions in the std::fs module. 6/13
2 replies 0 retweets 0 likesShow this thread -
Replying to @stjepang
While this is a convenient way to do it in general, it disregards the ability for runtimes to implement optimizations for APIs that provide async disk io to userspace; i.e. io_uring and IOCP.
1 reply 0 retweets 1 like
We still don't have any async file implementations based on IOCP/io_uring, and we might not for a while. Even the Go runtime still does all file I/O as blocking operations. Your point is valid, but I wonder if IOCP/io_uring bindings will ever expose a traditional file API...
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.