[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Is Lua the next big thing?
- From: Rici Lake <lua@...>
- Date: Tue, 13 Mar 2007 00:29:23 -0500
Brent Fulgham wrote:
My main concern is threading support. Our application is heavily
threaded, and I want to ensure that any embedded scripting engine is
able to be isolated from other threads. I have spent quite a bit of
time cleaning up an earlier home-grown interpreter (previously created
in a typical fit of NIH syndrome) that had horrible thread isolation
problems (such that if the same loop variable was used in two separate
instances of the interpreter, both variables would be incremented during
the loop). Needless to say, it's not hard to exceed this level of
quality but not that I've cleaned up the old mess, I want to *enhance*
things, rather than run the risk of creating new problems.
Lua uses no mutable globals at all (aside from the ones in the standard
C library: errno and stdin&friends). A Lua_State is entirely
self-contained, and will not interfere with any independently created
Lua_State, which is more or less the equivalent of an "interpreter
instance". So you're not going to run into any threading issues which
you don't create yourself :)
The coroutine mechanism is not implemented with threads, although the
API calls them threads (which they are, but not OS threads); Lua threads
are exposed as instances of a Lua_State, and those Lua_States are
related to each other. You probably don't want to run those
simultaneously in different OS threads, but it is theoretically
possible; the language does not provide any synchronization primitives,
though, so you need to implement your own so that related Lua_States
don't trod on each other's globals.
If anyone can give me a pep talk about Lua in a C++ environment, I'd
love to be pointed to any references or success stories. I have just
read Roberto's Lua book (2nd Edition) but don't have much practical
experience with the language.
I'm not sure what you need to know. Lua can be compiled as C++, and if
you do that it will use C++ exceptions instead of setjmp/longjmp for
error handling (this is all tweakable, but that's the default.) I
personally don't do a lot of C++ programming, so I can't really give you
a C++ pep talk, but it's wonderfully simple to integrate into a C
application and I don't see why C++ would be any different.