b508964db6
This bound existed for two primary reasons, both detail below, and both of which have now been solved. One of the primary reasons this existed was due to the presence of `tailcall`. Each standard combinator will call `tailcall` as appropriate, storing the resulting trait object. Storing trait objects influences the applicatoin of the `Send` and `Sync` bounds normally, but a key insight here is that we're not storing trait objects but rather just pieces of otherwise internal futures. With this insight the main storage for these futures, `Collapsed`, could simply implement `Send` so long as the future itself originally implemented `Send`. This in turn means that `tailcall` must be an `unsafe` method, but it seems well worth the benefit of relaxing the `Send` bound. The second primary reason for this bound was so the `Task` itself could be send. This is critical for ensuring that futures can receive notifications from multiple threads (e.g. be a future waiting on sources of multiple events). Another key insight here, however, is that only the *outer* future needs to be `Send`. We already have a solution, with `LoopData`, to make non-`Send` data `Send`. By implementing `Future` directly for `LoopData<F: Future>`, this means that it's trivial to make any future sendable by simply pinning it to an event loop! With these two pieces combined, it means that `Send` is no longer needed as a bound on the `Future` and `Stream` traits. It may practically mean that `LoopData` is used commonly in some scenarios, but that's quite a small price to pay for relaxing the requirements of the core trait. Some other ramifications of this change are: * The `Future::boxed` and `Stream::boxed` methods now require `Self` to adhere to `Send`. This is expected to be the most common case, and in the less common case of not-`Send` `Box::new` can be used. * Two new type aliases, `BoxFuture` and `BoxStream` have been introduced to assist in writing APIs that return a trait object which is `Send`. Both of these type aliases package in the `Send` bound. * A new `LoopPin` type, added in the previous commit, can be used to easily generate handles that can be used to pin futures to an event loop without having a literal reference to the event loop itself.
futures-mio
Bindings to the mio crate implementing the futures-io and futures
abstractions.
Usage
First, add this to your Cargo.toml:
[dependencies]
futures-mio = { git = "https://github.com/alexcrichton/futures-rs" }
Next, add this to your crate:
extern crate futures_mio;
Examples
There are a few small examples showing off how to use this library:
What is futures-mio?
This crate is a connection futures, a zero-cost implementation of futures in
Rust, and mio, a crate for zero-cost asynchronous I/O, and futures-io,
abstractions for I/O on top of the futures crate. The types and structures
implemented in futures-mio implement Future and Stream traits as
appropriate. For example connecting a TCP stream returns a Future resolving
to a TCP stream, and a TCP listener implements a stream of TCP streams
(accepted connections).
This crate also provides facilities such as:
- TCP streams
- TCP listeners
- UDP sockets
- Timeouts
- Data owned and local to the event loop
- An
Executorimplementation for a futures'Task
The intention of futures-mio is to provide a concrete implementation for
crates built on top of futures-io. For example you can easily turn a TCP
stream into a TLS/SSL stream with the futures-tls crate or use the
combinators to compose working with data on sockets.
Check out the documentation for more information, and more coming here soon!
License
futures-mio is primarily distributed under the terms of both the MIT license
and the Apache License (Version 2.0), with portions covered by various BSD-like
licenses.
See LICENSE-APACHE, and LICENSE-MIT for details.