Re: Co routine local data / best practices

[Jim Pryor <lists+lua@...>]

On Tue, Dec 01, 2009 at 03:07:13PM -0800, Chris Gagnon wrote:
>    I need to clarify i suppose, I did/do not intend to access the thread from
>    the co routine.
>    I only am trying to decide how best to get my refID in the cleanup
>    situation.
> 
>    Imagine the code:
> 
>    int iRet = lua_resume(pLuaState);
>    if (iRet != LUA_YIELD)
>    {
>        // the thread is dead, must unref it to let GC do it's job.
>        // how do i get the refID?
>    }
> 
>    What I'm trying to avoid is having some c side map between lua state
>    pointers and ref id's.
>    It make little sense to me that i can't somehow store that along with the
>    co routine so that i can avoid the lookup and management of that variable
>    size data structure.
> 
>    This is why I tried storing the refID on the co routines stack.
>    However was thwarted by errors in the lua script leaving the stack in a
>    function scope such that i couldn't get my value.
> 
>    After your response I tried a weak key table with both the key and value
>    being the thread, in this way i could set the thread to nil and GC would
>    do the rest.
>    This was also thwarted by errors, since the only way i can see to push a
>    thread onto the main state stack to set it nil in the thread table, is to
>    call pushthread on the co routine(which is dead hence the problem) and
>    then move it to the main state stack.
> 
>    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 see, so you're not actually using the refIDs to lookup the threads,
just to keep them alive.

I don't have much experience working with threads C-side. Are you sure
that lua_pushthread(LThread) won't already do what you want? If L is the
state in which LThread was created, doesn't lua_pushthread(LThread) push
LThread onto L's stack? Does it really push it onto LThread's own stack?
I agree that the API looks to be either confusing or incomplete here.

If you could rely on LThread to return without errors, then you could
pass the refIDs to LThread on thread start, and return them on exit. But
you say you can't rely on that.

Then why not create a struct that has a slot for the refID and a slot
for the LThread, and pass that around between your functions, rather
than the LThread itself? Then:

    int iRet = lua_resume(pMyStateWrapper->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.

-- 
Jim Pryor
profjim@jimpryor.net