New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add task::LocalSet
API for running !Send
futures
#1733
Conversation
I would love any feedback on the API surface of the new |
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
This adds a marker type to the `Task` struct and `Schedule` trait indicating whether or not the task is `Send`, and changes `Task` to only implement `Send` when the `Send` marker is present. Schedulers must indicate whether they are capable of scheduling `Send` or `!Send` tasks. This solution is singnificantly better than the previous one of using an unsafe wrapper to make `!Send` tasks implement `Send`, which was necessary due to the bounds on the `Task` struct. Although the previous solution was correct, since the `!Send` tasks were only ever scheduled locally, the compiler could no longer verify that this was the case. Now, the typesystem actually _helps_ us ensure that schedulers that can only schedule `Send` tasks will never schedule `!Send` tasks. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
These assertions asserted that the scheduler was current in all calls to its methods. However, the `TaskSet::spawn_local` method allows scheduling tasks to be run on the `TaskSet` when it is _not_ currently running. Therefore, these assertions are wrong. This test moves the assertion to the _right_ place: when the scheduler actually _runs_ scheduled tasks. Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
df978a8
to
1c0cea1
Compare
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
@carllerche BTW, the local task set now requires the "rt-full" feature flag. this is because it now requires the "sync" feature (due to the use of Does that seem right to you? |
thanks @jonhoo! Signed-off-by: Eliza Weisman <eliza@buoyant.io>
} | ||
} | ||
|
||
fn with<F>(&self, f: impl FnOnce() -> F) -> F { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens when you nest with
calls? Looks like bad things might happen? Either we want to allow it or disallow it via panic.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Copied from `basic_scheduler` Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Motivation
In earlier versions of
tokio
, thecurrent_thread::Runtime
type couldbe used to run
!Send
futures. However, PR #1716 merged thecurrent-thread and threadpool runtimes into a single type, which can no
longer run
!Send
futures. There is still a need in some cases tosupport futures that don't implement
Send
, and thetokio-compat
crate requires this in order to provide APIs that existed in
tokio
0.1.
Solution
This branch implements the API described by @carllerche in
#1716 (comment). It
adds a new
LocalSet
type andspawn_local
function totokio::task
.The
LocalSet
type is used to group together a set of tasks which mustrun on the same thread and don't implement
Send
. These are availablewhen a new "rt-util" feature flag is enabled.
Currently, the local task set is run by passing it a reference to a
Runtime
and a future toblock_on
. In the future, we may also wantto investigate allowing spawned futures to construct their own local
task sets, which would be executed on the worker that the future is
executing on.
In order to implement the new API, I've made some internal changes to
the
task
module andSchedule
trait to support scheduling bothSend
and
!Send
futures.