> tasks are now migrated across threads by the scheduler, whereas in the old scheduler a single task was always run in the same thread.
Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue?
Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific scheduler, and said scheduler accepts no more task, that kind of things?
The implementation on master currently uses a single queue, but very shortly it will be converted to work stealing.
Tasks can be 'pinned' to their own scheduler (i.e. thread) with `spawn_sched(SingleThreaded)`, and this is very important for tasks that call foreign code that blocks.
That's about the extent of the configurability at the moment, but I anticipate at least one other 'mode' in the future for coping with blocking tasks that don't want to be pinned to a specific thread.
> Would this open the possibility of configuring schedulers ...
I've been assured that it's the plan. I have no idea how much of it works right now though. I've only done one build with the new rt and it doesn't involve tasks.
Is that done by having a single task queue with multiple schedulers, or through work-stealing by schedulers with no ready tasks in their queue?
Would this open the possibility of configuring schedulers (including individually)? E.g. ensuring a given task stays pinned on a specific scheduler, and said scheduler accepts no more task, that kind of things?