Re: Co routine local data / best practices

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

On Tue, Dec 01, 2009 at 07:29:57PM -0800, Chris Gagnon wrote:

>      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.
> 
>    From Lua 5.1 Manual
> 
>   lua_pushthread
> 
>  int lua_pushthread (lua_State *L);
> 
>      Pushes the thread represented by L onto the stack. Returns 1 if this
>      thread is the main thread of its state.
> 
>    Unlike most pushes that are like:
>    ��� void lua_pushtype( lua_State * L, type t)
>    the push thread function dosn't take enough parameters to know what stack
>    to push the thread onto.
>    incomplete? or some sort of protection against introducing a potentially
>    bad lua_state * into lua?
>    The later makes the most sense to me.

I think it may just be a confusing optimization. When you create some
objects (see the buffer methods like luaL_addstring), the buffer stores
a reference to the lua_State it was created in insider itself, so you
don't need to call luaL_addstring(L, B, s), you just call
luaL_addstring(L, s). I was speculating that perhaps lua_pushthread(L1)
would push the thread represented by lua_State L1 onto the stack of the
lua_State in which L1 was created. But maybe it pushes it onto L1's own
stack. I don't know, I've not used this piece of the API.

>      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.
> 
>    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.

Sorry, I don't understand what you're saying. I thought your management
code was handling threads running your users' lua scripts. Now you're
talking about lua scripts calling cfunctions that may yield---are the
cfunctions in the same thread as the lua scripts, and they might yield
that thread? Or are they in separate threads? Which agent here is doing
the thread management?

>    Really creating that map and management code could have been written in
>    less time then I've already spent trying to find a way to avoid it.� I
>    just seems like it shouldn't be necessary but every way I've attempted to
>    get around it has failed miserably.
> 
>    Maybe I'll bite the bullet and just create the map, but i won't sleep well
>    because of it.

I do understand the impulse to do it elegantly, even if it takes more
time...

-- 
Jim Pryor
profjim@jimpryor.net