state)
> Â Â Âï ïif (iRet != LUA_YIELD)
> Â Â Âï ï{
> Â Â Âï ï ï ï// push pMyStateWrapper->refID onto stack, unref the ThreadTable
> Â Â Âï ï ï ï// for that refID, and let GC do its thing on the thread..
> Â Â Âï ï}
>
> Â Â ÂThat seems too simple, I'm guessing you have some reason for avoiding it
> Â Â Âbut I don't see what it is.
>
> Â ÂMy reasoning for avoiding this is that when a lua script calls a cfunction
> Â Âthat may yield the signature is:
> Â Âïïï int function(lua_State *L)
> Â Âso to store this for a resume later on i would need to find the
> Â ÂpMyStateWrapper somewhere.
M = thread/co routine manager
S = some system that has registered a C interface for lua scripts to use
ÂÂÂÂÂÂ This may yield, i'll use the specific example of a system that impliments a Delay(fTime) function for scripts to use.
L = a co routine
M creates L and could create MyStateWrapper then starts L
L calls Delay(1.0) S gets a call to its registered function of signature int function(lua_State *L) and yields L
...1 second later...
S wants to Resume L however the resume requires MyStateWrapper so that is can properly clean up if the L ends or errors.
Now i must look up in a map that associates L with MyStateWrapper.
> I don't understand why the c api dosn't support:
> ÂÂÂÂÂ lua_pushthread(L, LThread)
> but i'm not out to change lua so this is only a curiosity.
I've wondered this too, but it's only one extra step to get what you want:
Âlua_pushthread(LThread);
Âlua_xmove(LThread, L, 1);
The issue i run into with this is that after an error running LThread lua asserts if i try to manipulate it's stack, which is troublesome if i need the thread or when trying to do tracebacks.
however i still need to look into this more, I'm unsure if there isn't something else going on.
-Chris
