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.
The logic that enables `CurrentThread::turn` to avoid unbounded
iteration was incorrect. It was possible for unfortunate timing to
result in a dead lock.
This patch provides a fix as well as a test.
FreeBSD uses a separate kqueue filter type for lio_listio. This change
adds support for that filter type. Full functionality will be provided
by the mio-aio and tokio-file crates.
* Add PollEvented::into_inner
Consumes a PollEvented and returns its inner io object. Useful for io
types that have exclusive ownership of a resource.
See also https://github.com/tokio-rs/tokio-core/commit/9400ffb
CurrentThread::turn uses a turn count strategy to allow `turn` to not
run infinitely. Currently, there is a bug where spawned tasks will not
get executed in calls to `turn`.
This patch fixes the bug by correctly setting the turn count for newly
spawned tasks.
This patch is an intial implementation of the Tokio runtime. The Tokio
runtime provides an out of the box configuration for running I/O heavy
asynchronous applications.
As of now, the Tokio runtime is a combination of a work-stealing thread
pool as well as a background reactor to drive I/O resources.
This patch also includes tokio-executor, a hopefully short lived crate
that is based on the futures 0.2 executor RFC.
* Implement `Park` for `Reactor`
This enables the reactor to be used as the thread parker for executors.
This also adds an `Error` component to `Park`. With this change, a
`Reactor` and a `CurrentThread` can be combined to achieve the
capabilities of tokio-core.
* move src/codec.rs -> src/codec/mod.rs
* Move traits Encoder and Decoder from src/framed_{read|write}.rs into src/codec/{encoder,decoder}.rs
* Move LinesCodec and BytesCodec from src/codecs.rs into src/codec/{lines,bytes}_codec.rs
The `Handle` type is intended to be used by end users of Tokio. The
wakeup functionlity is needed by executor implementations. It doesn't
make sense to put executor specific functionality on a type that is
intended for end users.
* Limit the max number of registered resources
This allows some token space to be used internally. Also, Mio 0.7 will
be limiting the token space some as well.
Mio: https://github.com/carllerche/mio/issues/788Closes#42
Generally speaking, it is unsafe to access to perform asynchronous
operations using `&self`. Taking `&self` allows usage from a `Sync`
context, which has unexpected results.
Taking `&mut self` to perform these operations prevents using these
asynchronous values from across tasks (unless they are wrapped in
`RefCell` or `Mutex`.
The caller should be required to have control of a reactor when setting
it as a fallback. A `Handle` is used to pass into libraries and
functions and should not grant capability of using the associated
reactor as a fallback.
Closes#71
std's `Incoming` iterator yields `TcpStream` instances. This patch
updates the `Incoming` future to match this signature.
This changes the yielded value from `(TcpStream, SocketAddr)` ->
`TcpStream`.
This was added oh-so-long ago and nowadays is just used by one consumer,
`PollEvented`. Let's just inline the already small implementation directly into
`PollEvented` which should make it easier to modify in the future as well
* Refactor UDP SendDgram & RecvDgram
Get rid of unnamed structs in the favor of private structs with named fields
* Change the signature of UdpCodec::encode
Now it is:
```
fn encode(&mut self, msg: Self::Out, buf: &mut Vec<u8>) -> Result<SocketAddr, Self::Error>;
```
Closes https://github.com/tokio-rs/tokio/issues/79
* Fix compilation error from `mio` crate
Carl Lerche