Some contexts, like EC2, have `Instant::now` as a relatively expensive function
to call. To help amortize the cost of this function this commit exposes a new
function on `Interval` and `Timeout` to pass in the assumed current time.
The `consume_queue` function can be relatively slow for an empty queue (the fast
path) so optimize this a bit with a preflight check that should just touch a few
atomics.
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.
Using Linux's `epoll(7)` interface, a `EPOLLHUP` condition is
signalled for the reading end of a pipe or socket when the other end
is closed for writing. This may happen in combination with `EPOLLIN`
being signalled (if further data is available for reading), or with
`EPOLLIN`.
If `EPOLLHUP` is signalled without `EPOLLIN` it indicates an immediate
EOF condition, which will result in the next `read()` suceeding with 0
bytes read. It is thus not required to handle `EPOLLHUP` specially in
the reader, but we need to indicate readiness upon encountering it.
Looking at the `kqueue` and `windows` mio backends, they seem to be
turn a detected EOF and connection reset into `mio::Ready::hup()`
events, so it may be reasonable to speculate that this change is an
improvement for these platforms as well.
Fixes#117.
Carl Lerche