lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Andrea:

On Tue, May 12, 2020 at 8:56 PM Andrea <andrea.l.vitali@gmail.com> wrote:
> and yes, your are right: environments such as Avionics/Automotive/Aerospace may require strict guarantees on worst case - and this is precisely why I am investigating this
> can Lua be made safer for these environments? (I mean in a seamless way: dropping in a replacement for the "table" type implementation)

A replacement hash table may aid you. But if you have hard realtime
requirements of the type "do this in that many  time units or people
die", you may also want to consider if a garbage collection scheme is
right for you. Times have changed, by I still remember the times where
I was not allowed to use dynamic memory allocation after control lopp
start ( because it is very hard to prove upper bounds for allocation
times under memory pressure, or even allocation success, so I
allocated fro the worst case on boot, before things got rolling ).

Also, dropping in a replacement hash table may be harder than it
looks, I have not looked too much, but I suspect its implementation
interacts with the garbage collector, I mean, the gc needs to know how
to collect from a table, and the weak reference stuff is also going to
need consideration.

For this kind of things it might be easier for you to implement other
data structures just in lua and use them where they are needed. In
fact, IMO, I would not use an interpreted language like lua for life
supporting things, I would go to a compiled language with a lot of
type checking and use a restricted set. Not for speed, but I've been
used interpreted languages for decaded, and I've had a program running
for more than a decade suddenly aborting due to an unexpected code
path I did not catch in tests on a typo which would not have even
compiled in C/C++/Java.

Francisco Olarte.
_______________________________________________
lua-l mailing list -- lua-l@lists.lua.org
To unsubscribe send an email to lua-l-leave@lists.lua.org