Josh Goebel

And so it seems you can indeed do it now in a dirty way by wrapping the fiber transfer inside a new fiber inside a function: ```js static addSelfToScheduler() {...

> but I'm afraid you don't understand the scheduler. That's always possible, but I'm honestly fairly certain I truly do here. :) Let me explain my understanding and you can...

The whole Scheduler system as written now truly "hides" a key part of the scheduling [state] in C callbacks... making it much harder to follow I think. If I was...

> You just add() fibers to be executed when the current fiber is paused. You had me thinking about this statement for a moment. **This is completely true**, but it's...

Your broadening the discussion a bit I think, which is fine. I was arguing (at a minimum) for a single small primitive to be added to Scheduler to allow people...

Your implementation looks like one viable possibility for building out the higher level pieces. It indeed solves "more of the problem" than mine did because I think you had more...

> I'm still not sure how to deal with fiber errors I purposely omitted errors from the discussion. I'd like to see some different approaches. I imagine dealing with errors...

> but we would have an another problem of an infinite transfer-back into the current fiber. I think this requires some small amount of support in Scheduler to do **nicely**....

For example adding a progress callback (to track the status of those downloads) to my system would be a single LOC: ```js static await(list, progressCallback) { while (true) { if...

Also the original problem could be solved another way with an `addAndStart` API: ```js var task = Task.run { Timer.sleep(1000) System.print("Task") } Scheduler.addAndStart { System.print("Non-task") } Task.await([task]) ``` That might...