lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


The L pointer isn't necessarily related to the master Lua state.  It can have a different value if a coroutine calls into your function.

wes

On Apr 15, 2012, at 12:00 PM, "Thijs Schreijer" <thijs@thijsschreijer.nl> wrote:

Iâ??m sort of stumbling along in my quest to learn c to create lua modules and every time I think I got it all figured out, something new pops up.

 

So now Iâ??m creating a C module and have defined some static variables. Now I read in PiL somewhere (couldnâ??t find it when I went looking for it) that static variables are a bad idea, this related to multiple lua states.

 

So my understanding is now, that if I create a c module â??mymoduleâ?? with a static variable, then if an application creates 2 lua states that each require â??mymoduleâ??, the c code of my module will be loaded only once, and be executed against the two different lua states.

This implies that the two states would then share the same static variable in my c module. Correct?

 

Because Iâ??m using async callbacks (on another OS thread), when one of the callbacks arrives, I cannot call into the lua state to collect the values from the registry or from an upvalue safely. This prevents me from putting all my static variables in a big struct and store that as a userdata in the registry or as an upvalue.

 

If I would incorporate L (from lua_State *L from a function call) into my data structures to identify to which lua state that structure belongs, would that be safe? Is L only valid during a single function call, or does it remain valid (and unchanged) for as long as that lua state exists?

 

Whats the best approach? Any help is appreciated.

 

Thijs