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
rt: Refactor Runtime::block_on
to take &self
#2782
Conversation
4dbc178
to
013e8ef
Compare
5569946
to
099da4c
Compare
fe4dcde
to
dd7fc15
Compare
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
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.
Thanks for taking this on 👍 Looks good overall. I left comments inline. I'll let @hawkw +1 the PR once the changes are done.
…to lucio/runtime-refactor
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.
lgtm overall --- a couple questions/nits.
pub struct TokioContext<'a, F> { | ||
#[pin] | ||
inner: F, | ||
handle: Handle, | ||
handle: &'a Runtime, |
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.
Hmm...unlike the prior version, this now has a borrow in it, so it's not 'static
. You'd have to write
let rt = ...;
some_other_future_executor::spawn(async move {
rt.wrap(some_future).await
});
rather than
let rt = ...;
some_other_future_executor::spawn(rt.wrap(some_future));
which seems like a minor ergonomic speed bump in what i imagine is more or less the most common use case for this?
Maybe we should just clone it...what do you think?
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.
So Runtime
doesn't implement clone anymore. But you can achieve the same thing if you async move { rt.wrap(fut) }
and if you warp the Runtime
with an Arc
you can clone before moving.
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.
We can revisit this in the near future.
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.
yup,
So
Runtime
doesn't implement clone anymore. But you can achieve the same thing if youasync move { rt.wrap(fut) }
and if you warp theRuntime
with anArc
you can clone before moving.
yup, i missed Carl's review feedback while looking at this. seems good to me, now that the arc is factored out. 👍
Co-authored-by: Eliza Weisman <eliza@buoyant.io>
I unfortunately do not have the spare cycles these days to review this, even though I wish I did :) |
@jonhoo its all good :) |
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.
lgtm!
This PR is the first in a series of PRs to solve #2720. This change introduces a few things.
Handle
has been removed from the public API (only used internally until we refactor it out, likely in an upcoming PR)Runtime::block_on
to take&self
. This change for the threaded runtime is quite trivial, but forbasic
/shell
runtimes we use aMutex<Option<Runtime>>
to allow the first call toblock_on
to do all the parking will subsequent ones (while the first one is not done yet) will just use the context from that firstblock_on
.Most of this PR is removing methods from
Handle
, refactoring the fact thatblock_on
is now immutable and makingCachedThreadParker
and friends available without any feature flags (I think this is correct there are no deps for it beyond std ones).Future work:
basic_scheduler
/shell
to embed theblock_on
implementation within their own structs rather than withinRuntime::block_on
. This means making thoseblock_on
's take&self
not&mut self
. Improve stealing the root parker in situations where it gets reset back into the mutex and another thread needs to now drive it.runtime::Builder
to removethreaded_scheduler
/basic_scheduler
and refactorcore_threads
to do the behavior described in rt: Runtime refinements #2720.#[tokio::main]
as described in chore: prepare to release 0.2.22 #2672.