RE: Reentrant GC

[Tim McCracken <Tim.McCracken@...>]

Pierre Chapuis wrote:
> I wonder how many companies have re-built basically this, with all the same tricks to interact with C code, event loops...

I suspect a lot! I am currently working on a similar system. I am following a "soft RTOS" model:   A single OS process will handle multiple "jobs", include a "global common" for shared data, and an embedded real-time(ish) database. Each "job" will include a Lua interpreter, prioritized event queue, recurring event scheduler,  and a few other features and additional/alternative standard libraries. Each "task" will be a Lua function.  And lots of value-added functionality - both generalized as well as application specific, which may vary based on the specific product.

I use the Lua interpreter  "out of the box" stock, although I have added some additional libraries. I have been very happy with Lua. I took the time to understand it's limitations, which in reality are very few since it can be easily extended through the API.  IMO, It is much easier to extend and embed than either TCL or Python. It is a great platform to add lots of value-added C/C++ code  and give users the ability to programmatically control functionality rather than just having access to configuration variables and tables - which is the norm for all of the systems I commonly work with. But I don't expect (or want) Lua to offer features that are part of the OS, or a 3GL library. What I really want from Lua is a structured, simple, scripting environment for end users to customize as required - any Lua is outstanding at that.  

There are (of course) language features I would like, many of which get discussed on this list regularly. But, in my case, they can all be accomplished with a few more keystrokes. *** For me the number one concern is the stability of the Lua language. ***   I am more than willing to adapt to, and take advantage of, changes in the C API with each new release. But in my ideal world, the Lua scripts that customers may develop need to work from one release to the next. So going forward, I really hope we ___rarely___ see changes that are not backward compatible.


> Sadly we cannot open source it.
The products I am working on will not be open source, but I am planning to have a fully functional (but limited in size) system for hobbyist/evaluation use at zero cost.