lua-users home
lua-l archive

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


Kevin,

Thank you for the follow up. Further to the execution of a specific
function, if I have a thread that has called a C function which invokes
lua_yield(), is there any way I can get the thread to begin execution of the
function from the top of the function body? Eg. The thread goes into a
Wait() function, waiting for some event, but while waiting for the event,
the C code decides the thread should start either the same function over
again, or switch to another one. What is the correct syntax for doing this?
Currently, calling the doit() function as you've shown below resumes
execution of the function body; it doesn't restart it. Do I need to flush
the stack somehow, or roll it back somehow? Or do I have to close the thread
somehow (since lua_closethread() doesn't exist!) or can I do something to
get it executing another function?

- Steven



-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Kevin Baca
Sent: Sunday, October 19, 2003 12:53 PM
To: 'Lua list'
Subject: RE: Running a script in each Lua thread.


You need to set up the globals table only once for each new thread.

The globals table will be GC'd when:

A. The thread is GC'd
B. You replace the table (and have no other refs to the old table)

The call to lua_gettable() is to retrieve the function that you're
resuming:

-- Call the doit() function
lua_pushliteral( L, "doit" )
lua_gettable( L, LUA_GLOBALSINDEX )
lua_resume( L, 0 )

One more thing:  Note that the docs mention lua_closethread().  This
function doesn't actually exist.  The thread is closed when it is GC'd.

-Kevin

> Is the setup of the table a one time thing that I have to do
> when creating a new thread? Do I need to perform any special
> operations to make sure it is GC'd? Also, is the call to
> get_table before each resume to push the thread's table into
> the global space? I'm still so new to this and appreciate the
> help so much.
>
> Steven
>
>
>
>
> -----Original Message-----
> From: lua-bounces@bazar2.conectiva.com.br
> [mailto:lua-bounces@bazar2.conectiva.com.br]On Behalf Of Kevin Baca
> Sent: Saturday, October 18, 2003 4:40 PM
> To: 'Lua list'
> Subject: RE: Running a script in each Lua thread.
>
>
> The docs on this are a little vague:
>
> Section 3.20
> ...
> Each thread has an independent global environment table. When
> you create a thread, this table is the same as that of the
> given state, but you can change each one independently. ...
>
> Where it says "you can change each one independently" that
> means you can
> *replace* each one independently.
>
> IOW, each thread can have a unique global table, but it's up
> to you to actually give each thread a unique global table.
>
> Here's some code that demonstrates this:
>
> C code
> ------
> lua_State* LA = lua_open();
> luaopen_base( LA );	//get the base lib
>
> lua_State* LB = lua_newthread( LA );
>
> //LB is an independent thread, but its globals
> //table is still the same as LA's globals table,
> //so we'll replace it with a new table.
> //The new table is set up so it will still look
> //to LA's globals for items it doesn't contain.
>
> lua_newtable( LB );    //new globals table
> lua_newtable( LB );    //metatable
> lua_pushliteral( LB, "__index" );
> lua_pushvalue( LB, LUA_GLOBALSINDEX );  //original globals
> lua_settable( LB, -3 ); lua_setmetatable( LB, -2 );
> lua_replace( LB, LUA_GLOBALSINDEX );    //replace LB's globals
>
> //Two scripts, each with a doit() function
>
> lua_dofile( LA, "scriptA.lua" );
> lua_pushliteral( LA, "doit" );
> lua_gettable( LA, LUA_GLOBALSINDEX );
> lua_resume( LA, 0 );
>
> lua_dofile( LB, "scriptB.lua" );
> lua_pushliteral( LB, "doit" );
> lua_gettable( LB, LUA_GLOBALSINDEX );
> lua_resume( LB, 0 );
>
> scriptA.lua
> -----------
> function doit()
>     print( "Script A" )
> end
>
> scriptB.lua
> -----------
> function doit()
>     print( "Script B" )
> end
>
> Hope that helps.
>
> -Kevin
>
> >
> >
> > Hello,
> >
> > I've searched through the archives and it has been very useful in
> > getting me started with lua. I'm at a bit of an impass
> right now and
> > am hoping someone on the list can help.
> >
> > Currently I am opening a lua_State, registering all of my C
> functions
> > with that, and then creating a new thread for each entity I
> need using
> > lua_newthread(). Subsequent to creatring a new thread, I
> load a script
> > to be run by that thread, and then use lua_getglobal(thread,
> > "funcname") to find the function I want to call in the
> script. then I
> > call lua_resume(). This works perfectly as long as the function
> > name is unique. The problem is I would like to have each
> > script have an Initialize() function. Unfortunately, the
> > Initialize() lua function of whichever script was last loaded
> > gets called no matter which lua thread I am resuming.
> >
> > What is the proper way of doing this? My application, like so many
> > others, is in a game system where I would like to be able to create
> > new game entities, attach a lua script to then, and let the script
> > run, using
> > lua_yield()
> > from within C functions to yield the scripts. I also would like to
> > keep my function names identical across all scripts to simplify the
> > calling interface from C code. I've tried using multiple lua_open()
> > calls to create seperate lua_States for each entity, but
> then I have
> > to register my C Functions for each new entity. This seems somewhat
> > expensive since we are targetting the console market where
> memory and
> > speed are a key requirement.
> >
> > I've seen some details in the archives but they all use
> > lua_cobegin() a function that is no longer available in lua-5.0.
> >
> > Any tips or even pointers to previous message threads about
> this would
> > be great. If worse comes the worse I can create a new
> lua_State using
> > lua_open() for each object, but that seems like too much overhead,
> > what with having to register the C functions each time.
> >
> > Many thanks for your time.
> >
> > Steven Brekelmans
> >
>