omg yet another way simon peyton-jones was wrong. cyclic task dependencies are problematic if you're a build tool and you expect to be able to infer the entire toposorted sequence of task invocations offline before executing them.
but if you are an operating system, there is no concept of global task completion (perhaps when PID 1 exits? do we still need a PID 1?), and you are constantly (in an online manner) selecting which live+active [with a nonzero remaining time slice] tasks to schedule on the available cores.
AND THE TASK SCHEDULER COULD BE A USERSPACE PROCESS TOO???????
i think a task scheduler process/service should be allocated from ring 0 and should have uncontested ownership over a set of hardware cores (i.e. no overlaps with other schedulers). and the scheduler should also have uncontested ownership over a set of live (not necessarily active) application processes.
and maybe application tasks can be explicitly+atomically migrated across schedulers? and maybe cores can be migrated across schedulers too.
and maybe there's an analogous kind of scheduler process for OS tasks (drivers, i/o sync)? so it can migrate cores with application schedulers, but not tasks (bc OS services are expected to have idiosyncratic scheduling requirements).
