Timothy Lochner

When the implementation of Wait() is to keep busy working on other tasks, it is assisting on the work queue while waiting. But waiting and just sleep-looping is equally bad. IMO, avoiding waits at all cost is worth the effort. This is what makes continuations worthwhile.

that's why I want continuations, to never explicitly wait but be fully reactive

waiting is an antipattern, pipelining and reactive-programming makes everything simpler and more efficient.

I wouldn't say waiting is an anti-pattern, but then I chose that approach for enkiTS so I guess that's already obvious. The wait approach is effective, and it simplifies the task manager (enkiTS is designed to be lightweight).

Yeah, the issue here is that we work in different worlds (You're realtime "I-know-my-task-set", I'm event driven long-live app "I-know-nothing-about-the-potential-task-set-of-the-app")

so waiting is almost always an antipattern because I don't know the work peak of the system (I have no control). So blocking a task should be avoided as much as possible. Keep it flowing, don't wait but spawn async continuations to be processed later when the data arrives

Then there's the "design argument": I want juniors to understand that data processing and business operation execution are not "algorithmic recipes" (Do this, wait for that, process that, etc) but a continuous flow of work, and as part of your work you could trigger more work

(Process input, process it in parallel, when done sum it, then serialize the result, etc)