My slab bump in #246 added a potential new panic in Core's Inner's
`cancel_timeout`.
Thankfully, the only way `cancel_timeout` can be called is from
TimeoutToken's `cancel_timeout`, which is crate-internal only and is
only called from Timeout's and Interval's drop fn's.
This change simply adds new clarifying documentation around
TokenTimeout's cancel_timeout to "future proof" anybody looking to use
cancel_timeout directly (not just on drop).
This patch disables various Unix-specific platform features that are
not enabled on Fuchsia. It also updates the mio version to 0.6.10,
which is the first release that supports Fuchsia.
This commit adds a general-purpose method for querying the readiness of a
`PollEvented` type. This new method, `poll_ready`, takes a blanket `mio::Ready`
and tests if any part of it is ready. The purpose of this is to expose
platform-specific events through `PollReady` such as `hup` and `error` events
other than just the platform-agnostic readable/writable events.
The semanatics of this method are:
* The `poll_ready` function takes a mask, and the return value is either
`Async::Ready` with a subset of these events that are ready or `None` if none
of them are ready.
* There can be up to two tasks blocked on a `PollEvented`, so we need to pick
which one is suitable for these new events. Currently all events are routed to
the `read` task unless the writable bit is set. This is mostly only relevant
for multi-task usage or if you're manually calling `need_read` and/or
`need_write`, and hopefully the docs will cover this now.
If the underlying read_bufs() call returned a WouldBlock error,
TcpStream.read_buf() was erroneously calling self.io.need_write(), when
it should actually call self.io.need_read().
* if remaining bytes are smaller then 8 * 1024, allocate 8 * 1024
* otherwise allocate as much as needed to hold the remaining bytes
without re-allocations.
The previous implementation would always use the capacity
of the previous buffer, which would effectively prevent it
from ever shrinking.
This also means that protocol with greater variance in
possible frame sizes would likely be heavily over-allocating.
If these implementations use zero-copy, this would imply
that even small frames kept alive by the client would use
large amounts of memory.
The change is motivated by the implementation of the
cassandra-protocol, which allows frames of up to 256MB
in size, which solely depend on the kind of query.
Alex Crichton