[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: ANN: Lua OS 0.4
- From: Stefan Reich <stefan.reich.maker.of.eye@...>
- Date: Thu, 18 Aug 2011 15:41:15 +0200
Hi Gregory!
On Wed, Aug 17, 2011 at 9:01 AM, Gregory Bonik <gregory@bonik.org> wrote:
> Hi Stefan,
>
> As far as I can understand from your reference manual, all sandboxes in
> one "cage" share one Lua VM. Is it safe to use multiple sandboxes with
> different "powers" inside one VM? I guess you set a separate environment
> for each thread, but anyway.
Yes, the powers are set per sandbox. "Empowered" sandboxes can coexist
with "powerless" sandboxes in one cage.
> Second, I've read in the manual that it's possible to set a timeout for
> a sandbox. This is really necessary, but shutting down the process which
> exceeded the timeout doesn't seem a good idea to me. I guess you limit
> the number of instructions via the debug hook. So is it possible to call
> lua_yeild from the debug hook instead of terminating the sandbox?
Yes, I thought about that too. You could call it "forced yields". The
thing is, I am not sure if that works.
The problematic case is when the thread is in the middle of a
sensitive operation when the debug hook hits. Specifically, when an OS
function is being executed. We don't want to yield then since it would
screw up the integrity of OS data structures. So we'd need a lock to
prevent yielding at the wrong moment.
Furthermore, there are callbacks from OS to user code. Message and
persistence handlers are called by the OS at arbitrary times. With
cooperative multitasking, user code decides when it is ready to accept
such calls. With forced yields, it could happen at any time.
I don't really think we should go down that route for now... we have
preemptive multithreading on another level. But someone could do a
liittle experiment on forced yields and see if they're feasible.
> Yes, things get
> complicated here since you'll need to implement a scheduler.
Yeah well, we'll need a cooperative scheduler anyway. Round-robin is
nice, but it would be even smarter to have a more flexible approach.
Stefan