summaryrefslogtreecommitdiffstats
path: root/tokio/src/io/async_read.rs
AgeCommit message (Collapse)Author
2020-10-21io: explain how to determine number of bytes read in AsyncRead (#3011)Zahari Dichev
Fixes: #2999
2020-10-16Update documentation of AsyncRead to reflect use of ReadBufJohn-John Tedro
2020-10-12io: Rename `ReadBuf` methods (#2945)Lucio Franco
This changes `ReadBuf::add_filled` to `ReadBuf::advance` and `ReadBuf::append` to `ReadBuf::put_slice`. This is just a mechanical change. Closes #2769
2020-09-24io: remove poll_{read,write}_buf from traits (#2882)Carl Lerche
These functions have object safety issues. It also has been decided to avoid vectored operations on the I/O traits. A later PR will bring back vectored operations on specific types that support them. Refs: #2879, #2716
2020-08-13io: change AsyncRead to use a ReadBuf (#2758)Sean McArthur
Works towards #2716. Changes the argument to `AsyncRead::poll_read` to take a `ReadBuf` struct that safely manages writes to uninitialized memory.
2020-05-30docs: replace method links with intra-links (#2540)xliiv
2020-05-21io: remove zeroing for AsyncRead implementors (#2525)Mikail Bagishov
2020-04-23io: track rustfmt/clippy changes (#2431)Alice Ryhl
Refs: rust-lang/rustfmt#4140
2020-01-24docs: use third form in API docs (#2027)Oleg Nosov
2020-01-21fix: Prevent undefined behaviour from malicious AsyncRead impl (#2030)Markus Westerlind
`AsyncRead` is safe to implement but can be implemented so that it reports that it read more bytes than it actually did. `poll_read_buf` on the other head implicitly trusts that the returned length is actually correct which makes it possible to advance the buffer past what has actually been initialized. An alternative fix could be to avoid the panic and instead advance by `n.min(b.len())`
2019-11-23docs: improve tokio::io API documentation (#1815)Carl Lerche
Adds method level documentation for `tokio::io`.
2019-11-20chore: update `bytes` dependency to git master (#1796)Carl Lerche
Tokio will track changes to bytes until 0.5 is released.
2019-11-15Limit `futures` dependency to `Stream` via feature flag (#1774)Carl Lerche
In an effort to reach API stability, the `tokio` crate is shedding its _public_ dependencies on crates that are either a) do not provide a stable (1.0+) release with longevity guarantees or b) match the `tokio` release cadence. Of course, implementing `std` traits fits the requirements. The on exception, for now, is the `Stream` trait found in `futures_core`. It is expected that this trait will not change much and be moved into `std. Since Tokio is not yet going reaching 1.0, I feel that it is acceptable to maintain a dependency on this trait given how foundational it is. Since the `Stream` implementation is optional, types that are logically streams provide `async fn next_*` functions to obtain the next value. Avoiding the `next()` name prevents fn conflicts with `StreamExt::next()`. Additionally, some misc cleanup is also done: - `tokio::io::io` -> `tokio::io::util`. - `delay` -> `delay_until`. - `Timeout::new` -> `timeout(...)`. - `signal::ctrl_c()` returns a future instead of a stream. - `{tcp,unix}::Incoming` is removed (due to lack of `Stream` trait). - `time::Throttle` is removed (due to lack of `Stream` trait). - Fix: `mpsc::UnboundedSender::send(&self)` (no more conflict with `Sink` fns).
2019-11-05fix clippy (#1737)Carl Lerche
2019-10-26io: move into `tokio` crate (#1691)Carl Lerche
A step towards collapsing Tokio sub crates into a single `tokio` crate (#1318). The `io` implementation is now provided by the main `tokio` crate. Functionality can be opted out of by using the various net related feature flags.