Re: LuaLanes 3.1.0 and LuaJIT 2.0.0-beta9 Problem

[Benoit Germain <bnt.germain@...>]

2012/4/24 Glenn Schmottlach <gschmottlach@gmail.com>:
> I was hoping Mike Pall might chime in here and offer a suggestion.
>

Me too.

I got another look. It happens that LuaJITT's luaL_openlibs opens all
standard libraries, plus "bit" and "ffi", and also sets
[registry]._PRELOAD.ffi to some C function.
I haven't seen mention of a reserved _PRELOAD registry entry in
PUC-Lua, so I suppose this is LuaJIT-specific, and this entry is
likely a reference to package.preload.
Anyway. When Lanes creates a new Lua state, it doesn't call
luaL_openlibs to load all standard libraries. Instead it calls
individual luaopen_xxx functions based on the library list provided to
the generator. This is a (legacy) optimization in the event a program
creates *lots* of lanes and wants to shave as much overhead as
possible by skipping unnecessary base libraries.
For each listed library I grab the return value of luaopen_xxx and
scan it for all functions to store in a name<->function 2-way map.
Unfortunately, luaopen_jit and luaopen_ffi are not part of Puc-Lua
API, so I can't include them in the list of known base libraries.

So, the net result is that package.preload.ffi exists in the main Lua
state created by the LuaJIt interpreter, but I don't have a way to
load it in subsequently created Lua states besides forcing all Lua
states created by Lanes to load all base libraries through
luaL_openlibs. I have hacked a version that does this when provided
with the special "*" library list, and no longer fails on
lanes.configure().

But if some other option exists that keeps the optimization alive I'd
be happy to know about it. OTOH, maybe this optimization is useless
because nobody ever creates Lua states in so great numbers that it is
necessary, in which case I could just always use luaL_openlibs and be
done with it.


-- 
Benoit.