Re: void* in Lua_State for Application?

[Jean-Luc Jumpertz <jean-luc@...>]

Oops ! I was too quick to send my last message. And so I forgot the real reason for inserting the call to luai_userstatefree in close_state, one year ago or so.

Actually there was a good reason for which luai_userstateclose could not be used to free the private object associated to the main Lua thread.

As the comment in the posted code said,  the call to free the private object for the main thread need to be done "in lua_close (after having garbage collected all objects) */".
The reason for this is that the private object associated with the main thread needs to be alive when during the final GC call because it the __gc methods are called in the context of the main Lua thread. Having the private object freed at this point, as it would be if done in luai_userstateclose, caused a number of issues in the host application.
  
So the bottom line for this is the need for fine-grain synchronization between the lua-State ant the associated private data, i.e. that no Lua or native code call should be done in a lua_state after the corresponding luai_userstatefree or luai_userstateclose has been called.

What is your opinion about this?

Jean-Luc

Le 2 sept. 2013 à 15:01, Jean-Luc Jumpertz <jean-luc@celedev.eu> a écrit :

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