Re: CVS commit: src/sys

[Lourival Vieira Neto <lneto%netbsd.org@localhost>]

Hi Mindaugas,

On Sat, Jul 19, 2014 at 7:16 PM, Mindaugas Rasiukevicius
<rmind%netbsd.org@localhost> wrote:
> Alex,
>
> Alexander Nasonov <alnsn%yandex.ru@localhost> 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