rust/src/libstd/io
Alex Crichton 697de42f69 rollup merge of #23087: nagisa/std-undeadlock
Being a person who somehow has taken a liking to premature optimisation, my knee-jerk reaction to
locking in std handles was preamble resembling following snippet:

    let stdout = stdout();
    let lstdout = stdout.lock();
    let stdin = stdin();
    let lstdin = stdin.lock();

and then reading from the locked handle like this:

    let mut letter = [0; 1];
    lstdin.read(&mut letter).unwrap();

As it is now this code will deadlock because the `read` method attempts to lock stdout as well!

r? @alexcrichton

---

Either way, I find flushing stdout when stdin is used debatable. I believe people who write prompts should take care to flush stdout when necessary themselves.

Another idea: Would be cool if locks on std handles would be taken for a thread, rather than a handle, so given preamble (first code snippet)

    stdin.lock()

or more generally

    stdin.read(…)

worked fine. I.e. if more than a single lock are all taken inside the same thread, it would work, though not sure if our synchronisation primitives are expressive enough to make it possible.
2015-03-06 15:37:47 -08:00
..
buffered.rs Remove integer suffixes where the types in compiled code are identical. 2015-03-05 12:38:33 +05:30
cursor.rs Rollup merge of #23010 - alexcrichton:deprecate-some-old-io, r=aturon 2015-03-06 08:58:44 +05:30
error.rs
impls.rs std: Stabilize portions of the io module 2015-03-04 17:04:22 -08:00
lazy.rs std: Implement stdio for std::io 2015-02-28 23:13:02 -08:00
mod.rs Rollup merge of #23010 - alexcrichton:deprecate-some-old-io, r=aturon 2015-03-06 08:58:44 +05:30
prelude.rs
stdio.rs Fix an easy to trigger deadlock in std::io::stdio 2015-03-06 11:22:07 +02:00
util.rs std: Stabilize portions of the io module 2015-03-04 17:04:22 -08:00