Hi Mindaugas, On Sat, Jul 19, 2014 at 7:16 PM, Mindaugas Rasiukevicius <rm...@netbsd.org> wrote: > Alex, > > Alexander Nasonov <al...@yandex.ru> wrote: >> Lourival Pereira Vieira Neto wrote: >> > Module Name: src >> > Committed By: lneto >> > Date: Sat Jul 19 17:13:22 UTC 2014 >> > >> > Modified Files: >> > src/sys/modules/lua: lua.c >> > src/sys/sys: lua.h >> > >> > Log Message: >> > lua(4): added support for running Lua scripts in intr context >> >> Please revert this. You can't make a mechanical change >> (s/kmem_/kmem_intr_/g and so on) to enable lua in softintr >> context. You need to design it. >> >> What if GC kicks-in in softintr? What if the code tries to >> load a chunk of new code in softintr? And there are other >> questions. > > I have explained to Lourival that softint context is a very constrained > environment and he should seek for a better design, e.g. have per-CPU > Lua state while keeping such Lua programs mostly stateless and sharing no > global state. Ideally, we should have deterministic behaviour and memory > pre-allocation with such programs (whether it is Lua or not). > > This is tricky with Lua, but I think he understands the implications and > issues. The change is more of an initial step to (inefficiently) support > the capability. Meanwhile, those interested can research and experiment > with NPF+Lua. Such use of Lua is not really meant to be production-ready > at this point.
Yes, I think that I do understand the implications of running Lua in softint context. However, I don't think the best option is to have stateless Lua because we would lose functionality and it wouldn't be enough. For example, we could still have scripts performing infinite loops. We are circumventing this issue limiting the number of instructions executed by the Lua VM. Please also note that it is safe to Lua to fail to allocate memory. Moreover, I really prefer to finish its first use case and evaluate the issues before super-engineering it and stating that it is inefficient. Anyway, I think that we can continue discussing it and improving the design. I just don't think this is the case of reverting (especially, before trying to understand what is being done). Regards, -- Lourival Vieira Neto
