Re: callstack recursive environment

> compile the Lua script multiple times...

Hmm. Interesting idea, but it's a little bit outside my architecture,

which is this: my engine is already multi-threaded, and I maintain N+1 Lua

contexts, one per game AI thread plus one for the game's rendering thread,

since you can do lots of drawing stuff through the Lua extensions as well.

Each game object might run under any of those Lua environments at

any time, depending on which Posix thread happened to pop it off

the work queue (or deque, more properly).

But I pile a lot of stuff into these enivronments - many thousands of lines

of Lua code arleady, and I'm just getting warmed up :). It's OK for me

to multiply that by 5 or 9 or whatever # of threads there are, but I'd

rather not multiply it by hundreds or thousands - seems like a lot of stuff,

and a lot of time to re-parse it all from the .lua files.

Hey, thanks for the comments everybody. You guys are awesome :).

From: David Given <dg@cowlark.com>
To: lua-l@lists.lua.org
Sent: Saturday, March 24, 2012 5:30 PM
Subject: Re: callstack recursive environment

On 24/03/12 22:56, codemonkey Monkey wrote:
[...]
> Also, performance matters here, second after robustness; I don't want extra
> function calls in every Lua function. (In fact, I can optionally switch in
> LuaJIT to get more performance, and that's what I intend to use for real).
>
> I'm not trying to claim there's no way to do what I want, only that
> I don't know what the way is :). Seems like there must be one...

I suspect the simplest and most robust thing here is to simply compile
the Lua script multiple times, so each game object maintains a reference
to the compiled chunk that it runs. That way you get total control over
the environment by passing in whatever object you like as the fourth
parameter to load().

This has a number of advantages: it lends itself very nicely to an
architecture where each type of game object gets its own script, which
can then use local variables etc for speed in a completely natural way;
it allows you to easily extend things so you run your scripts in
multiple Lua states, if you want multithreading or better
compartmentalisation; and it may well simplify your APIs.

The big disadvantage, of course, is that you need to store multiple
compiled chunks in memory for the same piece of Lua code, but these
aren't large.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "Never attribute to malice what can be adequately explained by
│ stupidity." --- Nick Diamos (Hanlon's Razor)