3 ms·

What is the point of exposing a scheduler? Seems like that's another implementation detail that should not be exposed. The user should just instantiate some fib

• srean 10y ago
  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.
  • dkarapetyan 10y ago
    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.
    • srean 10y ago
      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.