[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Setting Global Tables
- From: "Peter Hill" <corwin@...>
- Date: Mon, 24 Feb 2003 16:35:49 +0800
Andrew Teirney:
> I am a fairly new person to lua, the version of lua i am using is
> 5.0(beta), since i don't have heaps of time to delve over documents etc i
> thought i might post this message to the users list in the hope someone
> might be able to explain a few things.
Has someone answered this yet? I haven't noticed a reply so here goes...
An easy one first...
> Also on another note, when lua loads a chunk presumably it stores it in
> memory, when the chunk has finished loading and then execution has
> subsequantly finished is the memory the chunk occupied free'd up?
In Lua all heap data (strings, functions/chunks, tables, userdata) is kept
allocated while the program still has a reference to it. After the last
reference disappears it remains allocated (but inaccessible) until the next
GC, at which time it is collected.
An example using a chunk:
c = loadfile("test.lua") -- There is a reference to the chunk in 'c'.
c() -- The chunk is called but there is still a reference in 'c'.
c() -- Indeed, it can be called again...
c = nil -- The last reference to the chunk is gone (there was only one)
-- so it may now be GCed.
If you had called the chunk directly:
loadfile("test.lua")()
or alternately
dofile("test.lua")
then the reference would be transitory and the chunk made available for
GCing almost immediately.
> In my current system which is an embedded project i have what i call a
> managment system (written in c), along with a number of support modules.
> These support modules will be available to the lua scripts. The intended
> use of the lua scripts is to be able to give the software new behaviour
> without having the need to compile to native code etc. Lua suit my needs
> perfectly, well from what i can see.
> Anyway, one of my support modules is responsible for processing a stream
> of text input, it breaks it up into fields as it comes in and so forth.
> When a particular sequence of character is received an event is generated.
> This event in turn causes either one or multiple scripts to execute
> depending on the configuration. The problem i am facing, probably due to
> my infancy of knowledge with lua is how can i make these string that the
> module has split up avaible to lua.
> So far i have thought of having a global table, lets say called
> 'fields'. on getting a new field to add at the c source level somehow poke
> it into the lua environment into that 'fields' table. When the scripts
> have finished executing then simply assign nil to the 'fields' value and
> have the lua strings GC'd etc. I think i can see how this is done if lua
> calls a c function. But i am unsure how to do this when lua does not call
> a c function from lua land.
I don't exactly follow what you want here... :-(
But, assuming you are simply talking about returning data back from a
function call (whether it is a C function or a Lua script), there are
basically two ways.
(1) You may choose to alter global variables. Note, in both Lua4 and Lua5
one may alter which 'global variable table' the script sees (Lua4 and Lua5
achieve this in a different fashion, though) so you can have more control
over such changes.
(2) You may use a "return" statement. Ie, _chunks_ (including a file) may
return values in exactly the same manner that functions do! So one could
say:
x,y = dofile("test.lua")
If you are talking about passing information *into* the script then your
options are more limited. Once again you can use globals, however you can't
use a 'function argument' style to pass in values the way that you can
return them :-(, although the idea has had some recent discussion.
> If anyone can provide me with information on how i can do this, this
> would be greatly appreciated. Also i forgot to mention that when c code is
> running lua code is not, its is a single threaded system, based on
> co-operative multi-tasking. Depending on how long lua takes to execute its
> scripts it may or maynot become a pre-emptive multi-threaded system, this
> is yet to be determined.
A thing to keep in mind here... Lua is not (currently) designed to run
completely multitasking. IF your separate tasks each keep their *own* Lua
state then things should be fine (afaik) since Lua is now re-entrant
(keeping all of its global data in the state variable, unlike earlier
versions). And I'm assuming, of course, that your system routines (like
"alloc / free" etc) are also multi-tasking safe. :-)
But if you wish to have each of your multiple tasks access the same Lua
environment (perhaps by using threads) then you have a problem... because
the current implementation does not perform any critical section locking.
:-(
*cheers*
Peter Hill.
Ki: Contractors... high-paid leeches stealing our work.
Fooker: If you think of them as disposable employees, you'll feel much
better...