[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua usage in safety-critical systems
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Mon, 13 Feb 2023 13:01:04 +0100
On 05/02/2023 21:07, Roger Leigh wrote:
I'm new to the mailing list, and would be interested to know if anyone has used Lua in any sort of safety-critical system, in particular for regulated industries such as automotive or medical. If anyone has any examples of such use in a real product that would be really interesting and much appreciated.
For a bit of context, I'm currently investigating use of Lua in an embedded device running as a dedicated RTOS thread for high-level scripting of actions. I have developed an initial proof of concept with several safety mitigations including a custom pool allocator and made some other small modifications to make Lua work in this constrained environment. From a purely technical perspective, everything is working very well. However, without being aware of any precedence for Lua being used for this type of application, it is a potential regulatory risk, and so any pre-existing use of Lua for this type of situation would make it a less risky proposition.
If making the stock Lua source code work on embedded systems is of wider interest, I can potentially feed back some of the changes I've made which include:
- disabling of all file I/O for systems without any file system or FILE streams [mainly a handful of ifdefs]
- replacement of the random functions using clock() and time() with a hardware RNG [would weak symbols with a LUA_WEAK macro be acceptable, or should this go into Lua_State as a function pointer like for the memory allocator?]
- replacement of some of the output/logging functions to use alternative means of logging in the absence of FILE streams (same question as for the random functions regarding weak symbols or function pointer)
Many good answers in the thread. I would add that if you are designing a
real time system (I assume that since you plan using an RTOS), probably
any kind of garbage collected language (like Lua) poses problems, since
it is very hard or nearly practically impossible to predict deadlines,
even in a non-preempted implementation like Lua's.
In particular, IDK if Lua's garbage collector could be forced to run
with a /guaranteed/ upper bound on its execution time.
This is particularly crucial with hard RT systems, not to mention in a