Skip to content

Towards removing std::io #9749

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

Merged
merged 10 commits into from
Oct 10, 2013
Merged

Towards removing std::io #9749

merged 10 commits into from
Oct 10, 2013

Conversation

alexcrichton
Copy link
Member

This implements a number of the baby steps needed to start eliminating everything inside of std::io. It turns out that there are a lot of users of that module, so I'm going to try to tackle them separately instead of bringing down the whole system all at once.

This pull implements a large amount of unimplemented functionality inside of std::rt::io including:

  • Native file I/O (file descriptors, *FILE)
  • Native stdio (through the native file descriptors)
  • Native processes (extracted from std::run)

I also found that there are a number of users of std::io which desire to read an input line-by-line, so I added an implementation of read_until and read_line to BufferedReader.

With all of these changes in place, I started to axe various usages of std::io. There's a lot of one-off uses here-and-there, but the major use-case remaining that doesn't have a fantastic solution is extra::json. I ran into a few compiler bugs when attempting to remove that, so I figured I'd come back to it later instead.

There is one fairly major change in this pull, and it's moving from native stdio to uv stdio via print and println. Unfortunately logging still goes through native I/O (via dumb_println). This is going to need some thinking, because I still want the goal of logging/printing to be 0 allocations, and this is not possible if io::stdio::stderr() is called on each log message. Instead I think that this may need to be cached as the logger field inside the Task struct, but that will require a little more workings to get right (this is also a similar problem for print/println, do we cache stdout() to not have to re-create it every time?).

@alexcrichton
Copy link
Member Author

r? @brson @olsonjeffery

/// Reads the next line of input, interpreted as a sequence of utf-8
/// encoded unicode codepoints. If a newline is encountered, then the
/// newline is contained in the returned string.
pub fn read_line(&mut self) -> ~str {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it make more sense to put these on ReaderUtil?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was actually thinking of avoiding that. The only real way to implement these with a generic read function is to read one byte at a time, and that isn't really performant at all for anything that's not a buffered reader.

@brson
Copy link
Contributor

brson commented Oct 9, 2013

Some comments:

  • In general we want the io::native modules to present an interface that is compatible with the non-blocking interface, so that std::io can multiplex between them based on the execution context.
  • read_line should probably be done as part of the general 'encoding' subsystem that doesn't exist yet. That said, this function is pretty critical for porting std::io users, so we can live with this for now.

I'm not sure whether it should only be defined for BufferedReader or just on ReaderUtil. My inclination is that it should probably be available on all readers.

Additionally, this moves the prelude imports of print/println from std::io to
std::rt::io.

Closes rust-lang#6846
These two functions will be useful when replacing various other counterparts
used by std::io consumers.
This changes the implementation to instead use rt::io::native::process as well
as an example of using those bindings.
This was just a mistake that it was hidden.
bors added a commit that referenced this pull request Oct 10, 2013
This implements a number of the baby steps needed to start eliminating everything inside of `std::io`. It turns out that there are a *lot* of users of that module, so I'm going to try to tackle them separately instead of bringing down the whole system all at once.

This pull implements a large amount of unimplemented functionality inside of `std::rt::io` including:

* Native file I/O (file descriptors, *FILE)
* Native stdio (through the native file descriptors)
* Native processes (extracted from `std::run`)

I also found that there are a number of users of `std::io` which desire to read an input line-by-line, so I added an implementation of `read_until` and `read_line` to `BufferedReader`.

With all of these changes in place, I started to axe various usages of `std::io`. There's a lot of one-off uses here-and-there, but the major use-case remaining that doesn't have a fantastic solution is `extra::json`. I ran into a few compiler bugs when attempting to remove that, so I figured I'd come back to it later instead. 

There is one fairly major change in this pull, and it's moving from native stdio to uv stdio via `print` and `println`. Unfortunately logging still goes through native I/O (via `dumb_println`). This is going to need some thinking, because I still want the goal of logging/printing to be 0 allocations, and this is not possible if `io::stdio::stderr()` is called on each log message. Instead I think that this may need to be cached as the `logger` field inside the `Task` struct, but that will require a little more workings to get right (this is also a similar problem for print/println, do we cache `stdout()` to not have to re-create it every time?).
@bors bors closed this Oct 10, 2013
@bors bors merged commit 4137471 into rust-lang:master Oct 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants