Re: [ANN] Lunatik -- NetBSD kernel scripting with Lua (GSoC project

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Oct 12 2010 at 02:17:35 -0300, Lourival Vieira Neto wrote:
> On Tue, Oct 12, 2010 at 1:50 AM, David Holland 
> <dholland-tech%netbsd.org@localhost> wrote:
> > On Tue, Oct 12, 2010 at 12:53:10AM -0300, Lourival Vieira Neto wrote:
> >  > > > > A signature only tells you whose neck to wring when the script
> >  > > > > misbehaves. :-) Since a Lua script running in the kernel won't be
> >  > > > > able to forge a pointer (right?), or conjure references to methods 
> > or
> >  > > > > data that weren't in its environment at the outset, you can run it
> >  > > > > in a highly restricted environment so that many kinds of 
> > misbehavior
> >  > > > > are difficult or impossible. ?Or I would *think* you can restrict 
> > the
> >  > > > > environment in that way; I wonder what Lourival thinks about that.
> >  > > >
> >  > > > I wouldn't say better =). That's exactly how I'm thinking about
> >  > > > address this issue: restricting access to each Lua environment. For
> >  > > > example, a script running in packet filtering should have access to a
> >  > > > different set of kernel functions than a script running in process
> >  > > > scheduling.
> >  > >
> >  > > ...so what do you do if the script calls a bunch of kernel functions
> >  > > and then crashes?
> >  >
> >  > if a script crashes, it raises an exception that can be caught by the
> >  > kernel (as an error code)..
> >
> > Right... so how do you restore the kernel to a valid state?
> 
> Why wouldn't it be a valid state after a script crash? I didn't get
> that. Can you exemplify it?

I *guess* what David means is that to perform decisions you need a
certain level of atomicity.  For example, just drawing something out of
a hat, if you want to decide which thread to schedule next, you need to
make sure the selected thread object exists over fetching the candidate
list and the actual scheduling.  For this you use a lock or a reference
counter or whatever.  So if your lua script crashes between fetching the
candidates and doing the actual scheduling, you need some way of releasing
the lock or decrementing the refcounter.  While you can of course push an
"error branch stack" into lua or write the interfaces to follow a strict
model where you commit state changes only at the last possible moment,
it is additional work and probably quite error-prone.

Although, on the non-academic side of things, if your thread scheduler
crashes, you're kinda screwed anyway.