Lua provides a fine example of Direct Language Embedding. The language was designed expressly for being embedded in a host application as well as for being extended with calls to other languages. It's no surprise then that it is very clean and simple to use in this way. I like Lua a lot.
Unfortunately, as you know from your own work, Rob, there is a big difference between using an embedded language inline with its host application's main or single thread of execution, and turning the language into a concurrent execution environment that can run multiple user scripts at the same time, which we need here. As I explained briefly to Ricky, to achieve the latter requires a multiprogrammed runtime to be created within the viewer, using either one of the multitasking approaches such as preemptive timeslicing plus a scheduler or alternatively coroutine-style cooperative yielding, or else using system threads to run multiple language runtimes concurrently. Whichever approach is used, a concurrent runtime would have to be added to the viewer to handle either the internal multitasking or the interations between system threads, and on top of that, one would then add an API to the world-related aspects of the viewer. It would be a non-trivial job. In the case of Lua, the clear winner for DLE is to spawn a system thread running a Lua VM for every Lua user script that needs to run, and let the system worry about executing them concurrently and scheduling between them. That's easy, but much hard work remains because simply having N separate Lua scripts running without interacting with the viewer is of no use at all, so a communications system needs to be built within the viewer to manage its interactions with these concurrent threads. (Letting each Lua script access any needed viewer code directly and concurrently through a simple C++ binding is of course not viable --- the viewer is not internally thread-safe, and locking calls gets us deep into concurrency horrors.) I like using Lua as it is designed to be used, running inline with an application's main thread of control (ie. no concurrency). I use it for flexible configuration and very easy testing of applications. Lua is also quite well suited for implementing large chunks of applications, everything excluding those functions that need to run at bare-metal speed like rendering. For example, it would be perfectly viable for the entire 2D GUI of the viewer to written as a suite of Lua scripts, each one invoked from C++ only when the appropriate GUI element requires attention. However, these scripts would have to be short and non-blocking --- one would not have the freedom of writing Lua scripts in the normal way with arbitrary loops and extended calls to external facilities, and multiple Lua scripts would not run concurrently. This is why the process-based approach is being recommended. It eliminates the work of implementing a multiprogrammed environment for scripts, letting the system do all the hard work (*really* hard work, because of concurrency). Instead, it requires socket handling, but that is quite short and simple sequential code. Depending on how one wishes to serialize communications, the amount of work here can vary --- calling JSON encode/decode routines is typically very easy, but handling buffering and exceptions can introduce some significant work. That's the in-viewer work overhead of this approach: socket handling and serialization. It's a *lot* less than the work overhead in DLE, and the flexibility that results from users being able to write plugins in any language they want and calling any libraries they want and using normal programming styles is a major win. Morgaine. =================================== On Mon, Mar 8, 2010 at 10:44 AM, Rob Nelson <nexisentertainm...@gmail.com>wrote: > On Sun, 2010-03-07 at 18:19 -0800, Ricky wrote: > > So far, barring any LL concepts, we have (as far as I know so far!) > > two designs of plugin system: > > 1: Socket-based plugins - as suggested by Morgaine. > > 2: D-Bus or similar existing IPC tool. > > 3: C++ Dynamically Shared Objects - my suggestion. > > You forgot interpreted scripts, such as Lua. Already implemented and > working in the Luna viewer. A lot easier to develop for, as well, since > users don't need to have an API to use it. All they need to know is how > to make it work and where to dump their files. > > The largest issue is sandboxing and threading, actually. I still have > to make an override for the io.* functions that will not access > materials outside of lua/data or the plugin's folder, and creating a > working event queue is becoming a major pain in the neck. > > Fred Rookstown > Luna Viewer (http://luna-viewer.googlecode.com) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
