Currently, the runtime does not shutdown if the runtime handle is
dropped. This can happen during a panic or when the value is simply
dropped.
This patch forces the runtime to shutdown if it is not explicitly
shutdown.
Fixes#209
If a future panics from within the context of a thread pool, the pool
should not be impacted. To do this, polling the future is wrapped with a
catch_unwind. Extra care is taken to ensure that `thread::panicking()`
is set from within the future's drop handle.
Fixes#209
This patch relicenses the Tokio project exclusively under the MIT
license. Before this, the project was dual licensed under MIT and Apache
2. As such, switching to only MIT is permitted.
Fixes#202
This patch fixes a bug where `CurrentThread::turn` is expected to block
even if the executor is idle.
The `turn` API is the low level interface for callers to interact with
the `Sleep` instance used by the `CurrentThread` instance. As such, a
call to `turn` is expected to call `sleep` once if the executor did not
perform any work.
This patch updates `poll_read_ready` to take a `mask` argument, enabling
the caller to specify the desired readiness. `need_read` is renamed to
`clear_read_ready` and also takes a mask.
This enables a caller to listen for HUP events without requiring reading
from the I/O resource.
Currently, if a thread pool instance is dropped without being shutdown,
the workers will run indefinitely. This is not ideal as it leaks the
threadpool.
This patch forces the thread pool to shutdown on drop.
Closes#151
Mio will be requiring `deregister` to be called explicitly in order to
guarantee that Poll releases any state associated with the I/O resource.
See carllerche/mio#753.
This patch adds an explicit `deregister` function to `Registration` and
updates `PollEvented` to call this function on drop.
`Registration::deregister` is also called on `PollEvented::into_inner`.
Closes#168
Some of the benchhmarks were broken and/or using deprecated APIs. This
patch updates the benches and requires them all to compile without
warnings in order to pass CI.
The exampes included in the repository have lagged behind the changes
made. Specifically, they do not use the new runtime construct.
This patch updates examples to use the latest features of Tokio.
Tokio is moving away from using `WouldBlock`, instead favoring
`Async::NotReady`.
This patch updates the TCP and UDP types, deprecating any function that
returns `WouldBlock` and adding a poll_ prefixed equivalent.
Currently, `tokio::spawn` matched the `spawn` function from futures 0.2.
However, this adds additional ergonomic overhead and removes the ability
to spawn from a drop fn. See rust-lang-nursery/futures-rs#830.
This patch switches the behavior to access the thread-local variable
referencing the default executor directly in the `spawn` function.
This allows libraries that require access to reactor related types to
depend on this crate without having to depend on the entirety of Tokio.
For example, libraries that implement their custom I/O resource will
need to access `Registration` or `PollEvented`.
This patch updates the documentation for a number of APIs. It also
introduces a prelude module and an io facade module, re-exporting types
from tokio-io.
Sometimes, passing ownership to an executor is necessary. For example,
some libraries require taking ownership of one.
This patch adds a function that returns an executor associated with a
runtime.
This patch makes a significant change to how I/O resources bind to a
reactor. Currently, an I/O resource (TCP, UDP, PollEvented) will bind
itself with a reactor upon creation.
First, some history.
Originally, tokio-core required that I/O resources be explicitly
associated with a reactor upon creation by passing in a `&Handle`. Tokio
reform introduced a default reactor. If I/O resources do not specify a
reactor upon creation, then the default reactor is used.
However, futures tend to favor being lazy. Creating a future should do
no work, instead it is defining a computation to be performed once the
future is executed. Binding an I/O resource with a reactor on creation
goes against this pattern.
This patch fixes this by allowing I/O resources to lazily bind to a
reactor. An explicit `&Handle` can still be used on creation, but if no
reactor is specified, then the default reactor is used. However, this
binding happens during execution time (read / write) and not creation.
Currently, the thread-local tracking the current thread executor is not
set when a task is dropped. This means that one cannot spawn a new
future from within the drop implementation of another future.
This patch adds support for this by setting the thread-local before
releasing a task.
This implementation is a bit messy. It probably could be cleaned up, but
this is being put off in favor of trying a more comprehensive
reorganization once the current thread executor is feature complete.
Sean McArthur