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
