-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filesystem manipulation APIs. #323
Conversation
This patch adds a new crate: tokio-fs. This crate provides a wrapper around `std` functionality that can only be performed using blocking operations. This primarily includes filesystem operations, but it also includes standard input, output, and error access as these streams cannot be safely switched to non-blocking mode in a portable way. These wrappers call the `std` functions from within a `blocking` annotation which allows the runtime to compensate for the fact that the thread will potentially remain blocked in a system call.
/// [std]: https://doc.rust-lang.org/std/fs/struct.File.html | ||
#[derive(Debug)] | ||
pub struct File { | ||
std: Option<StdFile>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should call it std_file
instead of std
?
tokio-fs/README.md
Outdated
|
||
## Overview | ||
|
||
This crate provides timer facilities for usage with Tokio. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
copy paste error here? Should filesystem facilities right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's unfortunate for non-blocking stdio to be totally unsupported, but I guess you have to worry about the case where a stdio fd might be a file fd.
//! | ||
//! Unlike *most* other Tokio APIs, the filesystem APIs **must** be used from | ||
//! the context of the Tokio runtime as they require Tokio specific features to | ||
//! function. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be weakened to "must be spawned on a tokio threadpool?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This version of the documentation is what is displayed in the tokio
facade.
The logic being that tokio-threadpool
is mostly hidden at this level.
pub use file::File; | ||
pub use stdin::{stdin, Stdin}; | ||
pub use stdout::{stdout, Stdout}; | ||
pub use stderr::{stderr, Stderr}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems kind of odd to have stdio under the filesystem module, even though the impl details are similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't disagree, but it seemed most appropriate in this crate. The crate could be named tokio-blocking-io
but that also is weird... Filesystem ops are the primary example of blocking io, so I just named it tokio-fs
.
It could be that it is worth splitting this logic out.
This patch adds a new crate: tokio-fs. This crate provides a wrapper
around
std
functionality that can only be performed using blockingoperations. This primarily includes filesystem operations, but it also
includes standard input, output, and error access as these streams
cannot be safely switched to non-blocking mode in a portable way.
These wrappers call the
std
functions from within ablocking
annotation which allows the runtime to compensate for the fact that the
thread will potentially remain blocked in a system call.