summaryrefslogtreecommitdiffstats
path: root/tokio-util
AgeCommit message (Collapse)Author
2019-11-16chore: migrate from pin-project to pin-project-lite (#1778)Taiki Endo
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-15codec: Remove Unpin requirement from Framed[Read,Write,] (#1758)Markus Westerlind
cc #1252
2019-11-07chore: update futures to 0.3.0 (#1741)Taiki Endo
2019-11-03test: unify MockTask and task::spawn (#1728)Carl Lerche
Delete `MockTask` in favor of `task::spawn`. Both are functionally equivalent.
2019-10-31Allow non-destructive access to the read buffer. (#1600)Jonathan Bastien-Filiatrault
I need this to implement SMTP pipelining checks. I mostly need to flush my send buffer when the read buffer is empty before waiting for the next command.
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.
2019-10-22codec: move into tokio-util (#1675)Carl Lerche
Related to #1318, Tokio APIs that are "less stable" are moved into a new `tokio-util` crate. This crate will mirror `tokio` and provide additional APIs that may require a greater rate of breaking changes. As examples require `tokio-util`, they are moved into a separate crate (`examples`). This has the added advantage of being able to avoid example only dependencies in the `tokio` crate.