RE: void* in Lua_State for Application?

[Thijs Schreijer <thijs@...>]

> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org] On
> Behalf Of Tim Hill
> Sent: zaterdag 31 augustus 2013 23:07
> To: Lua mailing list
> Subject: void* in Lua_State for Application?
> 
> I'm currently working on the third major project with Lua as an integral
> part, and in each project we've found it necessary to wrap a Lua_State*
> inside another structure that contains ancillary information (some
> statistics, a mutex, linked list pointers etc etc). I'm sure we're not the
> only ones doing this...
> 
> struct LuaPrivateState {
> 	lua_State* pVM;
> 	// Other state here...
> }
> 
> The problem with this, is that when Lua calls out to a support C function,
> that function gets the usual Lua_State* pointer (so it can access the Lua
> stack etc), but for some of these functions it is necessary to also access
> the ancillary state that is "outside" the Lua_State itself.
> 
> The problem, of course, is how to convert a Lua_State pointer to the
> ancillary state (LuaPrivateState*) pointer. There are a bunch of ways to
> do this:
> 
> -- Put it in a global. Yuck and doesn't work when you have lots of states.
> 
> -- Stick it in the Lua Registry as a light userdata under a well-known
> key. This works, but is somewhat expensive compared to (say) a simple C
> pointer de-reference. In some cases the table lookup may be the bulk of
> the execution time of the C function.
> 
> -- Store it in TLS (thread local storage) so the thread running Lua can
> find it. Works, but again not cheap, and has to be setup dynamically when
> threads run Lua states. Also TLS is not very portable across platforms.
> 
> -- Store it in some structure indexed by the Lua_State pointer (e.g. an RB
> tree). Again, works but seems overkill for a pointer de-reference.
> 
> -- Play tricks with the Lua custom memory allocator, which allows an
> arbitrary void* to be associated with each Lua_State as a side-effect of
> providing a custom memory allocator. Fast, but kinda abusing a Lua
> facility.
> 
> I'm sure there are others as well.
> 

Not an answer to your question, merely a remark on states. Depending on whether you need the pointer to a State or to a thread/coroutine inside a state your solutions may not work properly. The lua_State you get could point to a coroutine, which might die anytime after you've stored it.
On 5.2 you might use the LUA_RIDX_MAINTHREAD [1] index to get the mainthread for the state. But that will also cost you one registry table lookup.

Thijs

[1] http://www.lua.org/manual/5.2/manual.html#4.5