lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Gregory:

On Thu, Aug 18, 2011 at 5:21 PM, Gregory Bonik <gregory@bonik.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
this point.

> 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... :)

-Stefan