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.

The only way the wait in enkiTS should cause a deadlock is if you have two tasks waiting on each other. This is a programming error which would easily be found since the program would always deadlock.

Not quite. If you have 4 threads, it's likely that another thread calls wait() and picks up the dependent task, safely making sure that the originally waiting task doesn't deadlock. This is also why I always test on 1 thread in addition to coreCount threads.

That can't happen in enkiTS, or we're misunderstanding each other (easy on twitter). I also test on 1 to hardware thread count threads.