Separate context switching from multithreaded scheduling

[brson]

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.

[catamorphism]

Bug triage. Seems like an internal (non-blocking) issue to me.

[toddaaro]

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?

[brson]

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.

[toddaaro]

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.

[huonw]

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.

[emberian]

I also don't understand this, but Scheduler lives in libgreen.

[thestinger]

#17325 means this is no longer relevant to the standard libraries.