Private data

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Private data

Curt Carpenter
Title: Message
Does anyone have any good suggestions for how to deal with getting back to some private instance data when in a global C function called by Lua? Global variables are not an option, and there could be multiple instances of lua running.
 
It's easy enough to modify Lua to add this as part of the state, but is there a more correct way to do this that doesn't require modifying Lua?
 
Thanks,
 
Curt
Reply | Threaded
Open this post in threaded view
|

RE: Private data

Josh Jensen
Title: Message
The registry?  And does multiple instances mean multiple unique states of Lua (not sharing the same global state) or multiple shared states (sharing the same global state)?
 
Josh
-----Original Message-----
From: Curt Carpenter [mailto:[hidden email]]
Sent: Wednesday, October 03, 2001 2:48 PM
To: Multiple recipients of list
Subject: Private data

Does anyone have any good suggestions for how to deal with getting back to some private instance data when in a global C function called by Lua? Global variables are not an option, and there could be multiple instances of lua running.
 
It's easy enough to modify Lua to add this as part of the state, but is there a more correct way to do this that doesn't require modifying Lua?
 
Thanks,
 
Curt
Reply | Threaded
Open this post in threaded view
|

Re: Private data

Luiz Henrique de Figueiredo
In reply to this post by Curt Carpenter
>Does anyone have any good suggestions for how to deal with getting back
>to some private instance data when in a global C function called by Lua?

How about upvalues (ie C closures)? There's also the registry, where you can
store anything you want.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Private data

Curt Carpenter
In reply to this post by Curt Carpenter
>>Does anyone have any good suggestions for how to deal with getting
back 
>>to some private instance data when in a global C function called by 
>>Lua?

>How about upvalues (ie C closures)? There's also the registry, where
you can store anything you want. --lhf

Upvalues won't work. I need a solution that applies to all functions
that could be called by Lua, including tag methods and call/line hooks.

Two people suggesting using the registry??? You guys scare me! :-) If I
were going to do that, I'd rather create a global variable in the lua
state and use that. But the point is I want a VERY fast O(1) map
(because it will be used all the time) from the lua_State to some
pointer into my own stuff. I think I'm going to resort to modifying Lua,
and I would make this a feature request for 4.1. 

Just add the following two functions:
LUA_API void * lua_GetPrivateData(lua_State *L)
{
    return L->pprivatedata;
}

LUA_API void * lua_SetPrivateData(lua_State *L, void * p)
{
    L->pprivatedata = p;
}
And add
	void * pprivatedata;
to the struct lua_State.

Reply | Threaded
Open this post in threaded view
|

RE: Private data

Curt Carpenter
Sorry, just to clarify, when you guys mentioned the registry, my brain
immediately misinterpreted that you were referring to the Windows
registry. I wasn't familiar with the Lua registry, which I just
discovered. I'll check that out.

-----Original Message-----
From: Curt Carpenter [[hidden email]] 
Sent: Wednesday, October 03, 2001 2:59 PM
To: Multiple recipients of list
Subject: RE: Private data


>>Does anyone have any good suggestions for how to deal with getting
back 
>>to some private instance data when in a global C function called by
>>Lua?

>How about upvalues (ie C closures)? There's also the registry, where
you can store anything you want. --lhf

Upvalues won't work. I need a solution that applies to all functions
that could be called by Lua, including tag methods and call/line hooks.

Two people suggesting using the registry??? You guys scare me! :-) If I
were going to do that, I'd rather create a global variable in the lua
state and use that. But the point is I want a VERY fast O(1) map
(because it will be used all the time) from the lua_State to some
pointer into my own stuff. I think I'm going to resort to modifying Lua,
and I would make this a feature request for 4.1. 

Just add the following two functions:
LUA_API void * lua_GetPrivateData(lua_State *L)
{
    return L->pprivatedata;
}

LUA_API void * lua_SetPrivateData(lua_State *L, void * p)
{
    L->pprivatedata = p;
}
And add
	void * pprivatedata;
to the struct lua_State.

Reply | Threaded
Open this post in threaded view
|

RE: Private data

Thomas Wrensch-2
In reply to this post by Curt Carpenter
On Wed, 3 Oct 2001, Curt Carpenter wrote:

> >How about upvalues (ie C closures)? There's also the registry, where
> you can store anything you want. --lhf
> 
> Upvalues won't work. I need a solution that applies to all functions
> that could be called by Lua, including tag methods and call/line hooks.
> 
> Two people suggesting using the registry??? You guys scare me! :-) If I
> were going to do that, I'd rather create a global variable in the lua
> state and use that. 

Err...Lua's registry is pretty fast, you aren't thinking of the Windows
registry, are you?

  - Tom


Reply | Threaded
Open this post in threaded view
|

RE: Private data

Luiz Henrique de Figueiredo
In reply to this post by Curt Carpenter
>Two people suggesting using the registry??? You guys scare me! :-) If I

I meant the Lua registry, not the Windows registry, as you have discovered.
I'm sorry about the confusion.

Just to be clear, the Lua registry is an ordinary Lua table that is available
for clients to use as they wish. For instance, libraries might store "global"
information there. See ldblib.c for an example.

The registry was introduced in 4.0 because clients (and the core) could no
longer store Lua information in static C variables, because multiple states
were now possible.

>And add
>	void * pprivatedata;
>to the struct lua_State.

If you really want to do this, then 4.1 is ready for it: simply #define a
suitable string for LUA_USERSTATE. See lstate.h.
--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Private data

Eric Ries
In reply to this post by Curt Carpenter
We implemented this same thing almost exactly. It was quite useful to get
from a lua_State * to a pointer for our C++ wrapper class. I've heard that
Lua 4.1 has some macros to make this easier, but I have not really
investigated.

Eric

> Just add the following two functions:
> LUA_API void * lua_GetPrivateData(lua_State *L)
> {
>     return L->pprivatedata;
> }
>
> LUA_API void * lua_SetPrivateData(lua_State *L, void * p)
> {
>     L->pprivatedata = p;
> }
> And add
> 	void * pprivatedata;
> to the struct lua_State.
>


Reply | Threaded
Open this post in threaded view
|

Re: Private data

James Hearn
> We implemented this same thing almost exactly. It was quite useful to get
> from a lua_State * to a pointer for our C++ wrapper class. I've heard that
> Lua 4.1 has some macros to make this easier, but I have not really
> investigated.
>
> Eric

When I had to do a similar thing, I cheated and just dropped a userdata that
was the 'this' pointer of the enclosing class into a global __SYSTEM table
in the lua state. Cheap, but it worked!

--James Hearn


Reply | Threaded
Open this post in threaded view
|

RE: Private data

Curt Carpenter
In reply to this post by Curt Carpenter
BTW, although the confusion is cleared up, accessing a table is still
needlessly slow. So I'm gonna stick with my solution and stick with my
request to add it for 4.1.

-----Original Message-----
From: Luiz Henrique de Figueiredo [[hidden email]] 
Sent: Wednesday, October 03, 2001 5:51 PM
To: Multiple recipients of list
Subject: RE: Private data


>Two people suggesting using the registry??? You guys scare me! :-) If I

I meant the Lua registry, not the Windows registry, as you have
discovered. I'm sorry about the confusion.

Just to be clear, the Lua registry is an ordinary Lua table that is
available for clients to use as they wish. For instance, libraries might
store "global" information there. See ldblib.c for an example.

The registry was introduced in 4.0 because clients (and the core) could
no longer store Lua information in static C variables, because multiple
states were now possible.

>And add
>	void * pprivatedata;
>to the struct lua_State.

If you really want to do this, then 4.1 is ready for it: simply #define
a suitable string for LUA_USERSTATE. See lstate.h. --lhf

Reply | Threaded
Open this post in threaded view
|

RE: Private data

Joshua Jensen
> >accessing a table is still needlessly slow.
> 
> Any table? Or just the registry?
> Do you have hard data on how much it slows your application? 
> We'd be interested in that. Thanks. --lhf

I'd like to interject here for a moment.  Obviously, Lua is a general
purpose language that some of us (me) try to customize greatly toward a
very specific task (such as the memory optimizations I did, which I'm
still going to post as soon as I get two seconds to do so).  I can't
speak for Curt, but I am most interested in Lua's performance (both
speed and memory) in games.  I understand that by dealing with a
typeless language, I am setting myself up for slower performance than a
typed language.  I won't give up the flexibility of Lua for the faster
performance of a typed language, but I am going to make it as quick as I
can for my applications.

That said, ANY type of table lookup is much slower than a straight array
access.  I don't believe Curt is asking for indexed arrays in Lua
itself, but by providing himself an array, he has very quick constant
time lookup for whatever functionality he needs it for.

I noticed this in Amped in the transition between Lua 4.0 and 4.1 Alpha.
Amped used to use a LOT of lua_ref() and lua_getref() calls.  I noticed
a frame rate slowdown between the two versions and the culprit was the
new hashed lookup for ref'ed items.  The simplest solution for me was to
rework my C code to not use the lua_ref() approach.  This is a place
where the more "array-oriented" approach of Lua 4.0 was preferred (from
a gaming standpoint).

(The second part of this was the increase in memory usage due to the use
of the table.  I don't have a copy of Lua 4.0 handy, but it seems to me
that Lua 4.0 didn't store the key TObject.. Only the value TObject.
Given the size of a TObject and the amount of refs I had, it was
impractical to access my data in this form anymore).

For this reason, I wish that indexed arrays were built into the Lua VM
as a specialized type.  This is, again, for gaming purposes, but the
memory saved for embedded platforms could be great, also.

Josh