about summary refs log tree commit diff
path: root/src/libstd/sys/cloudabi/shims/pipe.rs
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-38/+0
2020-04-26Fix stragglersSteven Fackler-1/+1
2020-04-26Update nameSteven Fackler-1/+1
2020-04-26Add Read/Write::can_read/write_vectoredSteven Fackler-0/+8
When working with an arbitrary reader or writer, code that uses vectored operations may end up being slower than code that copies into a single buffer when the underlying reader or writer doesn't actually support vectored operations. These new methods allow you to ask the reader or witer up front if vectored operations are efficiently supported. Currently, you have to use some heuristics to guess by e.g. checking if the read or write only accessed the first buffer. Hyper is one concrete example of a library that has to do this dynamically: https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
2019-04-27Stabilized vectored IOSteven Fackler-3/+3
This renames `std::io::IoVec` to `std::io::IoSlice` and `std::io::IoVecMut` to `std::io::IoSliceMut`, and stabilizes `std::io::IoSlice`, `std::io::IoSliceMut`, `std::io::Read::read_vectored`, and `std::io::Write::write_vectored`. Closes #58452
2019-04-10std: Add `{read,write}_vectored` for more typesAlex Crichton-1/+9
This commit implements the `{read,write}_vectored` methods on more types in the standard library, namely: * `std::fs::File` * `std::process::ChildStd{in,out,err}` * `std::io::Std{in,out,err}` * `std::io::Std{in,out,err}Lock` * `std::io::Std{in,out,err}Raw` Where supported the OS implementations hook up to native support, otherwise it falls back to the already-defaulted implementation.
2019-02-28libstd => 2018Taiki Endo-2/+2
2018-12-25Remove licensesMark Rousskov-10/+0
2018-01-11Add shims for modules that we can't implement on CloudABI.Ed Schouten-0/+32
As discussed in #47268, libstd isn't ready to have certain functionality disabled yet. Follow wasm's approach of adding no-op modules for all of the features that we can't implement. I've placed all of those shims in a shims/ subdirectory, so we (the CloudABI folks) can experiment with removing them more easily. It also ensures that the code that does work doesn't get polluted with lots of useless boilerplate code.