]> git.lizzy.rs Git - rust.git/blobdiff - src/libstd/rt/io/mod.rs
auto merge of #8600 : sfackler/rust/http, r=brson
[rust.git] / src / libstd / rt / io / mod.rs
index 3d2a064dfc7ea1e7c50fd4b3ceaf387d5b8b1b5a..8b18fbcfa45d8a46ec1df8098edbefecb74bbe7e 100644 (file)
@@ -19,7 +19,7 @@
 Readers and Writers may be composed to add capabilities like string
 parsing, encoding, and compression.
 
-This will likely live in core::io, not core::rt::io.
+This will likely live in std::io, not std::rt::io.
 
 # Examples
 
@@ -93,7 +93,7 @@
 (continuation-passing) style popularised by node.js. Such systems rely
 on all computations being run inside an event loop which maintains a
 list of all pending I/O events; when one completes the registered
-callback is run and the code that made the I/O request continiues.
+callback is run and the code that made the I/O request continues.
 Such interfaces achieve non-blocking at the expense of being more
 difficult to reason about.
 
 while still providing feedback about errors. The basic strategy:
 
 * Errors are fatal by default, resulting in task failure
-* Errors raise the `io_error` conditon which provides an opportunity to inspect
+* Errors raise the `io_error` condition which provides an opportunity to inspect
   an IoError object containing details.
 * Return values must have a sensible null or zero value which is returned
   if a condition is handled successfully. This may be an `Option`, an empty
 * XXX: How should we use condition handlers that return values?
 * XXX: Should EOF raise default conditions when EOF is not an error?
 
-# Issues withi/o scheduler affinity, work stealing, task pinning
+# Issues with i/o scheduler affinity, work stealing, task pinning
 
 # Resource management
 
@@ -429,7 +429,7 @@ pub trait Reader {
     ///         println(reader.read_line());
     ///     }
     ///
-    /// # Failue
+    /// # Failure
     ///
     /// Returns `true` on failure.
     fn eof(&mut self) -> bool;