Scheduling algorithms are dime a dozen and the default one provided by a runtime might not be suitable for a particular application. A user space scheduler would let you have finer control when you need it. You may have codepaths that are latency sensitive and those that are throughput sensitive.
That's not what this scheduler does. It simply bundles up some fibers. You don't have control over the actual scheduling. Relevant section of documentation
When a fiber would block, it suspends to the scheduler from the current thread. The scheduler will arrange to re-start the fiber when the port or channel becomes readable or writable, as appropriate. For ports, the scheduler adds the file descriptor associated with the port to an epoll set. In either case, the scheduler remembers which fibers are waiting and for what, so that the user can inspect the state of their system.
If no scheduler has been installed in the current thread, the fiber will... well, we don’t know yet! Either it blocks its thread, or it aborts. We don’t know.
In fact it is pretty clear there is zero control user has over any scheduling activity other than suspending and resuming. It is all driven by polling events internal to the implementation.
I was responding to your larger question. User space schedulers would be quite cool, don't know of a language that offers anything over and above a priority queue or timers.
