-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Separate context switching from multithreaded scheduling #6856
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Bug triage. Seems like an internal (non-blocking) issue to me. |
Not sure what exactly the goal is here. This hints at the backwards relationship between coroutines and tasks that used to exist, is that what this was referring to? |
Not sure how much I can clarify this. It's sort of a fuzzy issue about separation of responsibilities. The Scheduler type does two things: 1) provides a core of context switching between tasks; 2) provides a bunch of logic for coordinating the scheduling of tasks between threads. This feels like two different issues, deserving of two types. |
Ok, that phrasing clears things up. We want a Scheduler trait that provides logic for deciding what tasks to run where, and a ContextChanger trait that provides implementations of the context-changing functions. This could be a great place for default methods, as we could do custom schedulers as implementations of the Scheduler trait with the default implementations from ContextChanger. |
Triage: I'm not sure I understand this, and I don't really understand the scheduler code, but, as far as I can tell, this hasn't happened yet. |
I also don't understand this, but Scheduler lives in libgreen. |
#17325 means this is no longer relevant to the standard libraries. |
Fix `manual_map` suggestion for `if let.. else ... if let.. else` chain fixes: rust-lang#6847 changelog: Fix `manual_map` suggestion for `if let.. else ... if let.. else` chain
The Scheduler type has two distinct responsibilities: at its core it is just a way to coordinate coroutines on a single thread. On top of that are a number of mechanisms and policies for multithreading and I/O. There should be multiple types here.
The text was updated successfully, but these errors were encountered: