lua-users home
lua-l archive

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

On Mon, Sep 2, 2013 at 11:17 AM, Tim Hill <> wrote:

On Sep 2, 2013, at 6:29 AM, Jean-Luc Jumpertz <> wrote:

>> Le 2 sept. 2013 à 14:27, Roberto Ierusalimschy <> 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.


Hi Tim,

Would you explain a little bit more of how you play the trick? I would assume you compare the allocating size with the internal state object to see whether it's a state objects or other objects? but how do you get the state size in the first place? It is probably not reliable either right (what if one of userdata collides?)