Re: [wxlua-users] LuaLans threading, was Re: mingw compiling wxlua problems

[John L. <jla...@gm...>]

On Thu, Sep 20, 2012 at 6:28 AM, Victor Bombi <so...@te...> wrote:
>>
>> The big question is: Can wxLua know when the LuaLane created lua_State
>> is destroyed so that the associated wxLuaState can be destroyed too?
>
> My knowledge of lualanes "deepthings" is still not very big.
> But which is the usual way in which wxLua knows when the lua_State is
> destroyed?

It doesn't and that is the problem with coroutines as well.

In a normal program, wxLua creates the lua_State and so it controls
the life of the lua_State, running lua.exe and calling require("wx")
also works since the app really is the lua_State and so it lives for
the life of the wxLuaState.

The problem with coroutines and LuaLanes is that callback functions
can be created for wxWidgets to call on button presses, etc, and if
the original lua_State is closed behind the back of the wxLuaState the
invalid lua_State pointer will be used and the app will crash and
there's no way to prevent this. wxLua can cleanup after itself, but
not if it doesn't know when to do it.

If you have a clever idea please let me know and better yet, try it
out. I have been thinking that perhaps wxLua could create a unique
local variable in the new lua_State and wait for it to be destroyed. I
believe that even in this case there will be the grey area where the
lua_State is closing and deleting variables, but if our wxLua variable
hasn't been deleted yet we won't know and happily keep making new
variables or calling functions (imagine a mouse or drawing event
handler). I understand that in your LuaLanes case you will not be
connecting events from other threads, but I believe that proper
cleanup will still be required.

Regards,
     John