Josh Goebel

Do you have any thoughts on the specifics of my actual minimal proposal here: > Add support for add(fiber) to the Scheduler API If there any harm in making it...

I think (I'm not an expert, but I know some things) that real OS schedulers have the idea of a loop thru the FULL process list... the scheduler *interrupts* periodically...

> I don't agree. Your system is indeed easier to work with, for the programmer of the CLI. For the user... _It's equally easy for just a user._ We both...

> A simpler way will just to check if we have items in the queue. If yes, runNextScheduled_(). If not, Fiber.suspend(). This is both simpler and more performant. But both...

HA, I may have changed my mind - I need to noodle more before responding. I keep coming back to this is the user's responsibility. I get the feeling you...

I think feel like partially we're talking about different things here and that is complicating the whole discussion. I want to build some useful lower-level primitives (yes it is possible...

> This code can be left as-is with cancellation, or cancel by hand pretty easily. Well, sure if you're imagining we're also adding cancellation. :-) Then you'd just cancel the...

> The scheduler is a low level component. Messing with it is not something to be done. > Scheduler.yield() is a welcomed addition, along with all() and any(). This feels...

There may be another philosophical difference here (which we're discussing in other threads). I think (within reason) the more things someone can accomplish without recompiling the CLI is "good". IE,...

> "Low level" is a relative term Let's agree to strongly agree on that LOL. > Now, the only question is if we should open its internals. I think we...