Consider providing a Spawn trait #313
Comments
|
This also allows implementing some more concurrency primitives, like a futures-based Mutex: https://github.com/Diggsey/futures-spawn/tree/sync (Allocations could be reduced a little, but it's using purely safe code) |
|
Some notes from a discussion with @carllerche today:
|
This commit adds a new trait to the `future` module, `Spawn`. This trait has
only one method:
trait Spawn<F: Future<Item = (), Error = ()>> {
fn spawn(&self, f: F);
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Spawn` instances instead of a particular
executor.
A `Future::background` method was also added to ergonomically pass a future to
an executor and run it in the background. The two `oneshot` modules (sync and
unsync) also grew `spawn` and `spawn_fn` functions which will spawn a future
onto an executor, returning a handle to the resulting future. This can be used
to spawn work onto a specific executor and still get notified when the work
itself is completed.
Finally, an implementation of the `Spawn` trait was added to `CpuPool`. Due to
the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
|
I've opened a PR for this change: #455 |
|
also cc @antoyo, this is what we were talking about in Mexico a few weeks ago. |
|
Thanks for your great work. |
|
I played a bit with this new |
This commit adds a new trait to the `future` module, `Spawn`. This trait has
only one method:
trait Spawn<F: Future<Item = (), Error = ()>> {
fn spawn(&self, f: F);
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Spawn` instances instead of a particular
executor.
A `Future::background` method was also added to ergonomically pass a future to
an executor and run it in the background. The two `oneshot` modules (sync and
unsync) also grew `spawn` and `spawn_fn` functions which will spawn a future
onto an executor, returning a handle to the resulting future. This can be used
to spawn work onto a specific executor and still get notified when the work
itself is completed.
Finally, an implementation of the `Spawn` trait was added to `CpuPool`. Due to
the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
|
@antoyo I'm not really understanding the problem. Code would help (me at least) |
|
@antoyo oh so in futures-glib you'd have: impl<F> Spawn<F> for Executor
where F: Future<Item = (), Error = ()> + 'static,
{
// ...
}That'd just abstract the spawning of futures, but wouldn't allow abstracting over I/O. For I/O the tokio-io crate would be used with Now the tricky piece comes in when you actually want to do something concrete! For example issue a TCP connection in Hyper. For this Hyper has a trait where the default implementation uses a Does that make sense? |
|
Yeah, thanks. |
This commit adds a new trait to the `future` module, `Spawn`. This trait has
only one method:
trait Spawn<F: Future<Item = (), Error = ()>> {
fn spawn(&self, f: F);
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Spawn` instances instead of a particular
executor.
A `Future::background` method was also added to ergonomically pass a future to
an executor and run it in the background. The two `oneshot` modules (sync and
unsync) also grew `spawn` and `spawn_fn` functions which will spawn a future
onto an executor, returning a handle to the resulting future. This can be used
to spawn work onto a specific executor and still get notified when the work
itself is completed.
Finally, an implementation of the `Spawn` trait was added to `CpuPool`. Due to
the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
|
I started to look at this, but I have not managed to understand how I could do that. I also have a related question. P.S.: do you think we should continue this discussion elsewhere? If yes, where do you suggest? |
|
@antoyo ah yes so tokio-proto will need to be updated first here, as the only reason it needs a Also yeah unfortunately for now Also no worries continuing discussion here! Fine by me :) |
This commit adds a new trait to the `future` module, `Executor`. This trait has
only one method:
trait Execute<F: Future<Item = (), Error = ()>> {
fn execute(&self, f: F) -> Result<(), ExecuteError<F>>;
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Executor` instances instead of a
particular executor.
A `Future::background` method was also added to ergonomically pass a future to
an executor and run it in the background. The two `oneshot` modules (sync and
unsync) also grew `spawn` and `spawn_fn` functions which will spawn a future
onto an executor, returning a handle to the resulting future. This can be used
to spawn work onto a specific executor and still get notified when the work
itself is completed.
Finally, an implementation of the `Executor` trait was added to `CpuPool`. Due
to the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
This commit adds a new trait to the `future` module, `Executor`. This trait has
only one method:
trait Execute<F: Future<Item = (), Error = ()>> {
fn execute(&self, f: F) -> Result<(), ExecuteError<F>>;
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Executor` instances instead of a
particular executor.
The two `oneshot` modules (sync and unsync) also grew `spawn` and `spawn_fn`
functions which will spawn a future onto an executor, returning a handle to the
resulting future. This can be used to spawn work onto a specific executor and
still get notified when the work itself is completed.
Finally, an implementation of the `Executor` trait was added to `CpuPool`. Due
to the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
This commit adds a new trait to the `future` module, `Executor`. This trait has
only one method:
trait Execute<F: Future<Item = (), Error = ()>> {
fn execute(&self, f: F) -> Result<(), ExecuteError<F>>;
}
The purpose of this trait is to unify the various executors found throughout the
ecosystem. Crates which require the ability to spawn futures will now have the
option ot operate generically over all `Executor` instances instead of a
particular executor.
The two `oneshot` modules (sync and unsync) also grew `spawn` and `spawn_fn`
functions which will spawn a future onto an executor, returning a handle to the
resulting future. This can be used to spawn work onto a specific executor and
still get notified when the work itself is completed.
Finally, an implementation of the `Executor` trait was added to `CpuPool`. Due
to the differences in unwinding/panic semantics, though, the `CpuPool::spawn`
method which previously existed was not deprecated.
Closes #313
Given the number of different types of executors for driving futures, it seems worth providing a trait representing the ability to spawn a task with a future.
One option:
Implementation
The reason the function is
spawn_detachedis that there also are variants built on top of this primitive that return a future representing the completion of the spawned future:https://github.com/carllerche/futures-spawn/blob/inference/src/lib.rs#L21-L73SpawnHelperexists to make rustc happy in some cases. There could be better ways of implementing this entire abstraction so it is up for discussion.I also updated CPU pool to work with this
Spawntrait: https://github.com/carllerche/futures-threadpoolRelates to: tokio-rs/tokio-core#57, tokio-rs/tokio-core#77
The text was updated successfully, but these errors were encountered: