May be, but it depends on an external C module implementing the preemptive meachanism (also its "tasks" are limited to scripts written as strings, so they cannot work with Lua functions and closures without first marshalling all parameters and its environment into the script (which will be unmarshalled by the Task engine), and then marshall the results of the task to string using some "print" statement that will be unmarshalled by parsing the output with getTaskData().
So I think it will be quite slow (and not easy to integrate to communicate complex Lua structures made with tables with possible cyclic references)
I think it uses a separate instance of the Lua engine, so these are not "threads" sharing data with other threads and coroutines (they may envtually share the same allocator and heap, but how to pass references to objects in a Lua thread with objects in a Task or in another task ? You also need extra communication channels I think.
What is needed is (I think) a native integration with threads in the same engine instance to benefit of closures and avoid the extra (un)marshalling using possibly very long strings.
The typical usage shown is extremely complex to start with, and I don't understand the concept of "number of steps" in the "runLoop". We probably don't need that or this dramatically reduces the possible usages to some limited scriptable tasks that can run independantly of any context and jsut take some input, run, then return some ouput, without communiating anything with other tasks or normal Lua threads.
