[sldev] Re: LSL and geometry hierarchy issues

Mark Meijer meijer78 at gmail.com
Mon Jan 21 14:12:03 PST 2008

On 21/01/2008, Argent Stonecutter <secret.argent at gmail.com> wrote:
> Mark Meijer:
> > Actually I think Lua would be a brilliant candidate. I don't know
> > where you got the idea that it's heavy.
> Remember the constraints scripts run under.

All valid points, no doubt about it. And I'll have to admit that Lua
bytecode is not exactly known for being concise. But all things
considered, I still think Lua is a great candidate.

> First, concurrency.
> In a typical application where these scripting languages are used you
> typically have to deal with a few hundred concurrently executing
> scripts at the most. In SL, you have thousands... it's not unknown
> for a single avatar to have a thousand active scripts. That means
> that a context switch between one script at the lest can not be
> significantly more expensive than a subroutine call.

There are several ways in which concurrency of the level you describe
can be addressed with Lua, be it with built-in language features, a
cleverly programmed host, 3rd party libraries, or any combination
thereof. Depending on how you do it, even context switches may be a

> Second, migration.
> When a macro avatar with several hundred scripted prims crosses a sim
> border, every one of those scripts has to be serialized, copied to
> the new sim, restored, and restarted. The easiest and most efficient
> way to do this is to use relative pointers for everything, and have
> the virtual machine operate on that basis... then the memory image is
> automatically serialized. But converting an existing VM for do that,
> even in part, is daunting. It's hard enough that when I was faced
> with doing so last year (for Tcl) I bailed, and decided to use
> absolute offsets for shared memory segments... and even then it took
> me six months just to track down all the bugs caused by losing track
> of whether a pointer to a shared object or not and calling the wrong
> free().

Lua's VM would probably not need a lot of modification to support
this, if at all. Although I do think it will require a bit of code on
top of the core engine. And there is probably more than one way of
achieving this too. On the level of the VM, on the level of what is in
Lua called an environment, on the level of coroutines. Or even just a
simple custom table or datatype that houses everything you need, which
is a snap to add in Lua. With a little work, depending on the approach
taken, you can serialize the lot of it and re-instantiate it without
any real problems. What I'm not sure about is how it all would work
with Lua's garbage collector, but that's just because I'm not up to
date on how that thing works these days and I know there have been
some changes.

> Adding object-orientation makes the problem ten times harder, simply
> because of all the extra indirection that goes on.

Lua on itself is not an object oriented language, but it has a bunch
of meta features which enable the use of - among other things - object
orientation. And again, it allows this (and is actually done by lots
of people) in various different ways. So you can use OO, or not, as
you please, and the beauty of this is that it doesn't matter to the
underlying system. If you have a VM that can run the core Lua
language, and you can do this concurrently and serialize all over the
place and whatnot, all that (object orientation, and whatever else you
do with it) will automatically be supported. Because those meta
features are a handful of relatively simple, integral facilities of
the Lua language. A lot of the nice things you can do with Lua are, at
least in part, due to those meta facilities. They can be (and in fact
are extensively) used to add any number of features to your Lua
environment, without changing the core language, and therefore without
affecting the underlying system.

> And that's all ignoring the realtime issue... there's a classic hard-
> realtime deadline: a script can't be allowed to run over the end of a
> physics frame.

Depending on the taken approach to concurrency and a properly
sandboxed scripting environment, a Lua host can excercise a great deal
of control over who gets to run when and for how long. Lua is not
something I associate with hard-realtime problems, but neither is SL.
And if all else fails, creating a custom extension that handles this
specifically for SL should not be too difficult. At least in
comparison to many other scripting engines.

More information about the secondlifescripters mailing list