On 11/15/2012 07:44 PM, Alek Paunov wrote:
LuaJIT is currently not available for our secondary architectures, so this would need fixing first. ("not available" meaning exactly that, there is no fallback to a slow C interpreter mode or something like that.)Oh, I completely forgot the secondary architectures (besides ARM). Florian, you follow LuaJIT - what other architectures (except the clearly missing s390) should be covered ?.
ppc64 isn't supported, either.
I am commenting on the possibility for deploying LuaJIT FFI as a partial replacement (problematic + future) of the hand written or SWIG Python bindings in the first place, not switching the system language from Python to Lua. In a system tool/daemon written in Python: * Python loads libluajit.so (import lupa; from lupa import LuaRuntime; ...)
And this will reduce memory overhead? I doubt it. Every C object will be wrapped in a high-level Python object, a low-level Python object (provided by lupa), a Lua registry slot (used by lupa), and an FFI wrapper (provided by LuaJIT). Correctness requires that the GIL (or some other lock) is held while C functions are called through the FFI because LuaJIT is not reentrant.
There are some open issues, too. LuaJIT hasn't yet found a way to handle C preprocessor defines (which are often used to provide constants). There is not attempt at all to deal with conflicting declarations. If two modules need definitions for time_t or struct timespec, one of them will fail with an "attempt to redefine" error.
(Don't get me wrong, LuaJIT is a great piece of work.) -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
