[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ANN: Lua OS 0.4
- From: Stefan Reich <stefan.reich.maker.of.eye@...>
- Date: Thu, 18 Aug 2011 17:40:31 +0200
On Thu, Aug 18, 2011 at 5:21 PM, Gregory Bonik <firstname.lastname@example.org> wrote:
> Stefan Reich wrote:
>> 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.
> I beleive it's not true. Debug hook is called only when the execution is
> in the Lua VM, i.e. it cannot be called while the C code is running.
Well in Lua OS, OS code is Lua code too :) No custom C code planned at
> Anyway, I bet you call lua_error from the debug hook to stop the sandbox
> which exceeded the time limit -- why don't you worry about data
> integrity then? Technically, it's almost the same.
Oops. You're actually right. So we should have a "we're in OS code" flag anyway.
> We should, however, find out whether calling lua_yield from a debug hook
> is legal. Lua 5.1 documentation of coroutine.yeild says the following:
> "The coroutine cannot be running a C function, a metamethod,
> or an iterator."
> But the 5.2 reference manual doesn't have such wording. It is
> interesting whether this limitation really no longer exists or this is a
> mistake in the manual.
Are we doing any of that? I believe we're not...
>> Furthermore, there are callbacks from OS to user code.
> By the way, how and when do you call these callbacks? Do you pass them
> as arguments to resume() and execute right after yield() returns? I.e.
> like that:
> local events = coroutine.yield()
> for i, e in ipairs(events) do e() end
Yes, it's like that actually. Although the events could also just be
put in a variable somewhere.
> You could mark a sandbox which was forced to yield with a flag. When you
> resume a sandbox with such flag, just don't pass events to it and remove
> the flag.
Yes, that could work... so we'd have a sandbox that might be
unresponsive to events, but never blocking the whole cage.
You're making some really good points I must say. I might actually
implement this and see if it can be done... :)