Re: LuaLanes 3.1.0 and LuaJIT 2.0.0-beta9 Problem

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

2012/4/24 Glenn Schmottlach <gschmottlach@gmail.com>:
> Just to be clear, a program as simple as:
>
> local lanes = require("lanes")
> lanes.configure()
>
> Fails with the error I mentioned earlier. Are you suggesting that this code
> (instead) should look like the following?
>
> local lanes = require("lanes")
>
> lanes.gen( {required = {"bit", "ffi"}}, func_body)
> lanes.configure()
>
> This wouldn't (seem) to work since I can't even "configure" lanes. Your
> suggestion seems to only come into play when I'm trying to generate/create a
> lane associated with the function body.

What happens is that the lanes.configure() call attempts to create a
lane for the timer support feature by default. This triggers the
creation of the keeper states, which are populated with the contents
of all base libraries (because everything copied from one lane to
another transits through the keeper states).
Whenever a state is created (keepers included), I also copy over in the
newly created state the contents of package.path, package.cpath,
package.loaders and package.preload found in the main state (or
whatever is provided in the generator options table) so that the
hooked require finds packages in the same locations than when called
from the main Lua state (see lanes.c line
1594).

I suppose that when the LuaJIT interpreter creates the main Lua state
it manually populates package.preload.ffi with some C function. Because of this
I need it to exist in the newly created lane's Lua state, which isn't
the case because it is a plain Lua state that LuaJIT didn't get its
hands on.

So either LuaJIT's lua_newstate should always populate
package.preload.ffi (which might not be the best of ideas), or you
have to provide a C on_state_create function to lanes.configure that
will do it for you.
A third option is to call lanes.configure{ with_timers = false}. But
this will only postpone the problem to your first lanes.gen() call I
suppose...

In any event I need to investigate a bit more. But maybe Mike has an
idea how I should handle this particular problem?



-- 
Benoit.