lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


The C module just uses the Lua API and does not do anything OS specific.
    Sorry I do not quite understand the other remarks about having tasks only as strings. Every Lua program is a string to start with. 
   Run loop number of steps is just the number of opcodes you want to execute before returning control to the parent program.
     Communication between tasks is limited to passing tables and strings and not fancy shared objects. Recursive tables however should not be a problem. Communication right now will be managed by the parent task.



On Nov 29, 2018 2:54 PM, "Philippe Verdy" <verdy_p@wanadoo.fr> wrote:
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.


Le jeu. 29 nov. 2018 à 23:11, Milind Gupta <milind.gupta@gmail.com> a écrit :


What is needed is a way to control in Lua programs (essentially in a parent thread controling all the other threads it creates and monitors) the resource usage and inform the VM which metered operations are allowed or not, and the VM should provide such basic metrics: the timeslot which is requested or the amount of memory requested or no longer in use. Nothing more. Now we can design a parent thread to do whatever it wants to apply its own policy for the children threads it creates and controls so none of these children threads can abusely take all the resources needed by other competing children threads (including the parent thread itself which can be protected from being blocked by its children).

There is a Lua Library to do that: LuaStepper (https://luarocks.org/modules/aryajur/luastepper)