Re: ANN: Lua OS 0.4

[HyperHacker <hyperhacker@...>]

On Thu, Aug 18, 2011 at 07:41, Stefan Reich
<stefan.reich.maker.of.eye@googlemail.com> wrote:
> 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
>
>

I think the term you want is "critical section". A thread can ask that
it not be interrupted until it finishes some task (delimited by calls
to EnterCriticalSection and LeaveCriticalSection or similar). Of
course then you have to figure out what to do if a thread gets into an
endless loop in that section...

Long-running C functions are another possible issue. Even if you don't
provide any of your own, Lua still has some. e.g. what if a thread
does something silly like print(('gdfhfs'):rep(9999999999)) ?

-- 
Sent from my toaster.