Skip to content
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: Remove threaded_scheduler() and basic_scheduler() #2876

Merged
merged 43 commits into from Oct 12, 2020

Conversation

LucioFranco
Copy link
Member

This PR removes the ability to set the threaded_scheduler
and basic_scheduler directly via the builder methods. Now
to select the basic_scheduler you must use core_threads.

For now:

  • rt_core enabled and no rt_threaded, core_threads is ignored and will always use the basic scheduler
  • rt_core & rt_threaded, core_threads = 0 will use basic, core_threads = n, n > 0 will use threaded
  • no rt_core & no rt_threaded it will always use the shell runtime

There are two new follow up issues in #2720, one for running the basic scheduler on a bg threaded instead of a single threaded threaded runtime and a re-review of the docs.

Alot of the macros have also been disabled to allow tests to pass, I expect to follow up on this and nix a lot of our macro code to simplify it in a follow up PR.

Related issue #2720

This PR removes the ability to set the threaded_scheduler
and basic_scheduler directly via the builder methods. Now
to select the basic_scheduler you must use `core_threads`.
Comment on lines 136 to 150
// if let Some(v) = core_threads {
// rt = quote! { #rt.core_threads(#v) };
// }

// if let Some(v) = max_threads {
// rt = quote! { #rt.max_threads(#v) };
// }

if is_test {
rt = quote! { #rt.core_threads(0) };
}

// if is_test && core_threads.is_none() {
// rt = quote! { #rt.core_threads(0) };
// }
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't really care if we merge this, likely going to be rewritten in a follow up PR anyways.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't include #2906, so yes, it will be rewritten by that PR if this is merged first.

tokio/src/lib.rs Outdated
pub use tokio_macros::main;
pub use tokio_macros::test;
}
#[cfg(not(test))]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again here, this will be re-reviewed once I get to the macros. This Pr is just for the builder.

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-runtime Module: tokio/runtime C-enhancement Category: A PR with an enhancement or bugfix. labels Sep 25, 2020
@Darksonn
Copy link
Contributor

I have not yet looked at the code, but:

rt-core enabled and no rt-threaded, core_threads is ignored and will always use the basic scheduler

I really want to go away from situations where enabling features changes the behaviour of code that compiles without them. Can we have core_threads not exist at all when rt-threaded is disabled?

I'm also not convinced we should expose a runtime at all without rt-core. It makes sense to have one internally for e.g. blocking_recv, but I'd prefer if the shell runtime didn't exist at all from the user's point of view.

@LucioFranco
Copy link
Member Author

I really want to go away from situations where enabling features changes the behaviour of code that compiles without them. Can we have core_threads not exist at all when rt-threaded is disabled?

I'm also not convinced we should expose a runtime at all without rt-core. It makes sense to have one internally for e.g. blocking_recv, but I'd prefer if the shell runtime didn't exist at all from the user's point of view.

I agree, but we could likely tackle this in a follow up PR? Could you post these thoughts also in #2720?

@Darksonn Darksonn mentioned this pull request Sep 25, 2020
6 tasks
Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems reasonable.

tokio/src/runtime/mod.rs Outdated Show resolved Hide resolved
Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left an inline question. I didn't have time to finish a full review yet.

benches/spawn.rs Outdated
.threaded_scheduler()
.build()
.unwrap();
let runtime = tokio::runtime::Builder::new().build().unwrap();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory, this shouldn't work. A default builder should not enable the work-stealing scheduler. I would expect this to panic or enable the shell runtime.

Copy link
Member

@carllerche carllerche left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it is on track 👍 I didn't look at the mcro changes yet.

If it makes things easier, you can punt entirely on new_single_thread for this PR.

@carllerche
Copy link
Member

@Darksonn You can configure the diff viewer to disable whitespace changes. That will hide any changes in indentation from the diff.

@carllerche
Copy link
Member

@davidbarsky I think your doc comments are good, but they aren't in scope for this PR. I would just merge them, but the comments are out of date. I'd suggest you open your own PR to submit those tweaks 👍.

@carllerche
Copy link
Member

carllerche commented Oct 12, 2020

@Darksonn @LucioFranco Ok, this PR should be good to go. I merged in @Darksonn's macro PR and updated it to match the Builder names.

#[tokio::main(flavor = "multi_thread", worker_threads = "4")]

The change got a bit large. This is mostly due to the changes in how the rt-core feature flag works. Enabling "Hide whitespace changes" makes the diff a bit smaller.

Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read through it and didn't notice any trouble. I haven't looked that closely at docs though.

Copy link
Member Author

@LucioFranco LucioFranco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't approve my own PR but left some comments. I am assuming single thread is gone we will add this back in a follow up or is it gone forever?

// Intentionally single threaded to measure delays in propagating wakes
.basic_scheduler()
.worker_threads(0)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This to me doesn't make sense, why 0? I would imagine we should not allow that unless the multi thread runtime can be a current thread one?

let rt = tokio::runtime::Builder::new()
.basic_scheduler()
let rt = tokio::runtime::Builder::new_multi_thread()
.worker_threads(0)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here is this valid?

tokio-macros/src/entry.rs Outdated Show resolved Hide resolved
tokio-macros/src/lib.rs Outdated Show resolved Hide resolved
tokio/src/coop.rs Outdated Show resolved Hide resolved
@@ -1,3 +1,5 @@
#![allow(dead_code)]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this just dead in all cases? Should we cfg_attr this?

Shell,
#[cfg(feature = "rt-core")]
Basic,
pub(crate) enum Kind {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So no single thread runtime? or are we punting that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No single thread for now IMO. We can do that post. It's a lot easier to do a single-thread by hand now as you can throw Runtime in an arc.

tokio/src/task/blocking.rs Outdated Show resolved Hide resolved
@@ -3,16 +3,26 @@ cfg_io_driver! {
pub(crate) mod slab;
}

#[cfg(any(
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol this must have been fun

tokio-macros/src/entry.rs Outdated Show resolved Hide resolved
@LucioFranco
Copy link
Member Author

Will be merging this once CI passes, I plan to do a full review of the docs once this has been merged.

@carllerche
Copy link
Member

👍 merge this whenever CI passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-enhancement Category: A PR with an enhancement or bugfix. M-runtime Module: tokio/runtime
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants