[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Manual timeslicing the VM.
- From: Mike Pall <mikelu-0508@...>
- Date: Fri, 5 Aug 2005 17:02:45 +0200
Rici Lake wrote:
> >Oh, and BTW: do not mix coroutine.resume() (the Lua function)
> >with yielding from the line or count hook. It rips apart the
> >stack frame of the running Lua function. You really have to use
> >lua_resume() from C and carefully avoid touching the coroutine
> What problem precisely are you referring to here? Is this the issue
> that hooks don't have call frames?
Yes, auxresume() in lbaselib.c will gladly lua_xmove() the whole
stack frame of the Lua routine that was running while the hook
yielded to the callers thread. Unless you move it back exactly
as-is on resume, you'll get random errors (an assertion in
luaV_execute may catch it -- if you turned them on).
In RVM I solved this by abusing L->base and setting it equal
to L->top (simulating an empty stack). Upon resume L->base
is restored from L->ci->base. I use the same trick in lua_vyield()
to avoid moving the yielded results down. I just move L->base up
Of course this breaks the invariant L->ci->base == L->base. But
this is only while a coroutine is suspended. The things that can
happen then are quite limited. I only had to change the last line
in correctstack() (stack reallocation).
Seems to work fine so far (and might be useful to be adopted
in the standard Lua core).
> [... hooks don't have call frames...] Personally, I think that's a bug.
Well, others might conclude it's a feature. At least it's
slightly faster for things like count hooks.
But it makes other things harder. One could do away with some
contortions in the debug library. Just being able to register
any C or Lua closure to be luaD_call()'ed as a hook simplifies
many things. It would also enable yielding from a Lua hook
(this doesn't work right now -- you need to use a pure C hook).
Well, I have no fixed opionion which way is better.
But ... didn't we want to clean up some things with hooks anyway?
Especially the ci->tailcalls thing is really annoying for me right
now in LuaJIT. Synthesizing LUA_HOOKTAILRET events is a bit strange,
too. It would be much easier to just drop that counting and add a
LUA_HOOKTAILCALL event (like you suggested).
Debuggers need to know and they already do the counting themselves.
Why duplicate the work?
And it's not very helpful for anything else. Ok, you get a dozen
'(tail call): ?' lines in a backtrace. But there is no info available
anyway, so why print it? The fact that there were some tailcalls
inbetween is only mildly interesting to users.