Re: void* in Lua_State for Application?

[Tim Hill <drtimhill@...>]

On Sep 2, 2013, at 6:29 AM, Jean-Luc Jumpertz <jean-luc@celedev.eu> wrote:

> 
>> 
>> Le 2 sept. 2013 à 14:27, Roberto Ierusalimschy <roberto@inf.puc-rio.br> a écrit :
>> 
>>>> Lua team, could you consider adding this call to  luai_userstatefree in function close_state for a next version of Lua ? ;-)
>>> 
>>> There is already a "call" to luai_userstateclose in lua_close.
>> 
>> Hi Roberto,
>> 
>> You're right, luai_userstateclose is just appropriate for releasing/freeing the private pointer associated to the main thread. 
>> I don't know how I could have missed it...
> 
> 

Great suggestions everyone! For reference, after internal discussions, we decided to hide the private pointer using the "allocator hack". Reasons for this choice were as follows:

-- We wanted to do a private allocator anyway to track Lua VM memory usage statistics. So having the "ud" void* pointer was tailor-made for our needs.

-- We were reluctant to tinker with stuff that was drifting toward "internals" of the Lua system, particularly as we want to keep open the option to switch to LuaJIT at some point.

-- Simplicity; the allocator hack, for all that it is a hack, is a good deal easier to use than EXTRASPACE or any of the other suggestions so far. This is particularly true as in our app we treat Lua coroutines as just more Lua code, we don't really want to track or treat them differently from the main Lua_State.

Ideally, Eric's patch would be the best way to go for us. A nice, clean "sd" pointer with corresponding getter API (or macro). It's in the right place too; shared across all Lua coroutine states.

--Tim