Timothy Lochner

Anyway, current future has no continuations, so there's no much difference between passing the task pointer to be awaited and returning a future

BTW you have no plans to add continuations to enkiTS right? (Been evaluating different task engines for months and yours is one of the options heading the list. I don't want to write it myself and having to maintain it in production)

The current model in enkiTS is that tasks can call other tasks and waiting for tasks will run any available tasks. This means the stack can grow with each dependency, so I'm considering adding explicit dependencies.

In my experience with tasks, having Wait assist on the queue is a great way to cause deadlocks. I basically abolished Wait from my task library and put an explicit “AssistOnQueue()” function. Usage of it is considered code smell, but valid rarely.

What do you mean with "wait assist"? (I am not that familiar with the parallel programming slang) :P

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.