How I want to simplify async filesystem APIs... 1/13
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
-
-
What about the File type, though? In the vast majority of uses, files are only read or only written. Seeking is not a very common operation - in fact, I'd say seeking is a vestigial function that is now superseded by read_at()/write_at() functions. 7/13
Show this thread -
We need an adapter that takes anything implementing Read/Write and converts it into an async type implementing AsyncRead/AsyncWrite. Let's create functions reader()/writer() that look like this. 8/13pic.twitter.com/xY3aMJeyY1
Show this thread -
When reader()/writer() is called, a blocking task gets spawned that reads/writes data from the file and pipes it through an async channel. Here's how we'd convert a file into an async reader. 9/13pic.twitter.com/OvlQ6qZZwk
Show this thread -
Now we don't even need tokio::io::{stdin,stdout,stderr} anymore. Functions reader()/writer() can easily do asynchronous standard input/output. 10/13pic.twitter.com/iubNUkWfTX
Show this thread -
There's just one more async adapter... Similarly to reader()/writer(), let's create iter() that converts any blocking iterator into an async stream. 11/13pic.twitter.com/4rU0eYFAXg
Show this thread -
Function iter() comes in handy when listing files in a directory, for example. This is how we can list files asynchronously using the standard APIs from std::fs. 12/13pic.twitter.com/PN8NDo0KWN
Show this thread -
There you go. If we have blocking!(), reader(), writer(), and iter(), there's really no need to have modules like tokio::fs or even tokio::io. We can just use std::fs and std::io and apply async adapters to them! 13/13pic.twitter.com/Sym6Qbjnlf
Show this thread -
I forgot to mention: The blocking!() macro already exists and was first introduced in Bastion and it's really nice! https://docs.rs/bastion/0.3.5-alpha/bastion/macro.blocking.html …pic.twitter.com/rQjdrwX2ZZ
Show this thread
End of conversation
New conversation -
-
-
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.
-
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...
End of conversation
New conversation -
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.