[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ANN: Lua OS 0.4
- From: Gregory Bonik <gregory@...>
- Date: Thu, 18 Aug 2011 19:21:53 +0400
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.
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.
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.
> 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.
local events = coroutine.yield()
for i, e in ipairs(events) do e() end
> 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.
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