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
(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
/// println(reader.read_line());
/// }
///
- /// # Failue
+ /// # Failure
///
/// Returns `true` on failure.
fn eof(&mut self) -> bool;