wxlua-users

[Wxlua-users] Possible coroutine fixes

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

There is a problem with coroutines currently. The issue is that when
lua creates a coroutine a new lua_State is created by lua and wxLua
correctly associates the new lua_State with the original wxLuaState so
that it can get the ref data (where the bindings and C++ variables are
stored). This is all fine, however when you try to run some lua code
in a coroutine, lua calls the function "int LUACALL
wxLua_lua_getTableFunc(lua_State *L)" to find out about a bound
function. It needs to look up the wxLuaState (for the ref data) and
though the proper ref data IS found, subsequent calls to functions
like wxLuaState::ttag use the lua_State of the wxLuaState and not the
coroutine one and so it fails.

Solutions:

a) Remove all the ttag and other functions from the wxLuaState and
make them standalone 'C' functions that only take a lua_State* L. This
would require that the wxLuaState (and it's ref data) would have to be
incessantly looked up, this is how it was previously.

b) Add a parameter lua_State* L =3D NULL to the end of functions like
ttag (and EVERY function that would be called by a 'C' function called
by lua) that would either use the given lua_State passed in if !NULL
or use the lua_State of the wxLuaState. This is easy to do, but may be
a little confusing.

c) Make the ref data, the C++ data for the lua_State itself ref data.
     wxLuaState : wxObject
        -> wxLuaStateRefData (the wxObjectRefData)
                members are lua_State* and wxLuaStateData
     wxLuaStateData : wxObject
        -> wxLuaStateDataRefData (the wxObjectRefData)
                members are the rest of what is currently in the
wxLuaStateRefData

So that if you do "wxLuaState wxlState(lua_State* L)" it finds the
wxLuaStateRefData for the given lua_State, but since the
wxLuaStateData is also ref counted two or more wxLuaStateRefData can
share the same data, which is what coroutines require.

d) Make wxLuaState NOT ref counted and keep a list of pointers to them
for looking them up from the lua_State*. As a member it would have a
ref counted wxLuaStateData class, similar to the one outlined above.

e) ?

I'd appreciate any thoughts on this. In my effort to make the
wxLuaState more robust, I missed this important detail.

Regards,
    John Labenski

Re: [Wxlua-users] Possible coroutine fixes

[k. h. <kla...@nl...>]

Hi John,

John Labenski wrote:

>
>e) ?
>  
>
I hardly understand the problem. I do understand that there are two 
lua_State at the same time.
While there is only one wxLuaState.
What would be the problem if there would be two wxLuaStates too?
And what would be the solution if the new lua_State became part of every 
new wxLuaState, and that
was passed around using a Smart Pointer to it, instead of the current 
ref counting mechanism.
If several lua_State need to share data, that can be done using a second 
Smart Pointer inside wxLuaState.
It will be cleared properly if all wxLuaStates's are released ( no more 
smart pointers to it ).
I used hierarchies of smart pointers for storing drawing objects, and it 
works great.

I guess what i am trying to say can Smart pointers help here, as a more 
convenient way to share data.
For sure Smart pointer code is much easier to follow in C++ code.

What is exactly the reason you choose the current form of ref counting?

I do not know how and why wxLua is organized as is yet, so don't get mad 
if i am talking nonsense ;-)

Regards,

Klaas



-- 
Unclassified

Re: [Wxlua-users] Possible coroutine fixes

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

> I hardly understand the problem. I do understand that there are two
> lua_State at the same time.
> While there is only one wxLuaState.
> What would be the problem if there would be two wxLuaStates too?

Because the rest of the variables in the wxLuaStateRefData must be
shared between the two lua_States. You only know which lua_State you
want to use from lua calling the C function.

> And what would be the solution if the new lua_State became part of every
> new wxLuaState, and that
> was passed around using a Smart Pointer to it, instead of the current
> ref counting mechanism.
> If several lua_State need to share data, that can be done using a second
> Smart Pointer inside wxLuaState.

You still need a way to associate many lua_States with a single group
of data structures. I'm not sure how a smart pointer would help here.

> It will be cleared properly if all wxLuaStates's are released ( no more
> smart pointers to it ).
> I used hierarchies of smart pointers for storing drawing objects, and it
> works great.

Deletion is not so much a problem, I will look back at your smart
pointers. Another reason to have the wxObject ref mechanism is that
you can have a delayed construction, eg. make a wxLuaState a member of
a class and then Create it as necessary or not at all.

> What is exactly the reason you choose the current form of ref counting?

So that when you pass a wxLuaState to a wxLuaCallback (a handler for a
wxEvent) and then close the lua_State you want the wxLuaCallback to
know that the lua_State has been closed. It's a simple way to let
anyone who's given a wxLuaState that the lua_State is good or not. If
you just use pointers to the lua_State you have to track them all and
NULL them to avoid someone trying to use them. This can happen with
delayed window deletion in wxWidgets.

> I do not know how and why wxLua is organized as is yet, so don't get mad
> if i am talking nonsense ;-)

It's not too difficult, but there are some subtle intricacies.

Regards,
    John Labenski

Re: [Wxlua-users] Possible coroutine fixes

[klaas.holwerda <kho...@xs...>]

John Labenski wrote:

>>If several lua_State need to share data, that can be done using a second
>>Smart Pointer inside wxLuaState.
>>    
>>
>
>You still need a way to associate many lua_States with a single group
>of data structures. I'm not sure how a smart pointer would help here.
>  
>
The idea of smart pointers is that there are many Smart pointers 
pointing to the same data structure.
How many the count is,  is held within that data structure by the refcount.
So the idea is exactly that the same structure/class instance  is 
referenced/shared by several other objects,  which hold a smart pointer 
to that  structure/class as a member .
So if it would be possible to couple each new lua_State to a wxLuaState, 
where the last has a smart pointer to the shareddata structure/class, 
that  would  be oke.
This is i think you had in mind too, but doing it using refcounting the 
wxWidgets way, which is i think harder.
 

>>It will be cleared properly if all wxLuaStates's are released ( no more
>>smart pointers to it ).
>>I used hierarchies of smart pointers for storing drawing objects, and it
>>works great.
>>    
>>
>
>Deletion is not so much a problem, I will look back at your smart
>pointers. Another reason to have the wxObject ref mechanism is that
>you can have a delayed construction, eg. make a wxLuaState a member of
>a class and then Create it as necessary or not at all.
>  
>
Same with smart pointers i think. It initializes to zero, and once it is 
assigned a wxLuaState object, it will hold it. In principle a smart 
pointer acts almost like a normal pointer in mnay cases, only it deletes 
the object pointed to only when there or no more references. We have 
another even smarter pointer, which is able to reset all other smart 
pointers pointing to the same object. ( the object pointed to, has a 
list of all Smart pointer pointing to it. )
So it depends on what is needed.

>  
>
>>What is exactly the reason you choose the current form of ref counting?
>>    
>>
>
>So that when you pass a wxLuaState to a wxLuaCallback (a handler for a
>wxEvent) and then close the lua_State you want the wxLuaCallback to
>know that the lua_State has been closed.
>
That sounds like the smarTer pointer version;-)

> It's a simple way to let
>anyone who's given a wxLuaState that the lua_State is good or not. If
>you just use pointers to the lua_State you have to track them all and
>NULL them to avoid someone trying to use them. This can happen with
>delayed window deletion in wxWidgets.
>  
>
I see, i recognize this, often had that problem in wxWidgets.
Who is normally deleting a created lua_State? Is wxLua able to notice 
this event?

Hope it helps a little to decide what is best,

Klaas