LuaJIT - an alternative for current Python C bindings

[Florian Weimer]

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