Re: LuaLanes 3.1.0 and LuaJIT 2.0.0-beta9 Problem

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

2012/4/24 Glenn Schmottlach <gschmottlach@gmail.com>:
> This seems to imply that Lanes *must* be the first
> module loaded and lanes.configure() must be called *before* any other
> modules are loaded. Is this understanding correct?

yes.

>
> If this is true, I can see how this might be a problem with LuaJIT since
> both the FFI and BitOps modules appear to be "builtin" to the VM (and thus
> already exist when Lanes is first imported). Is there any way to tell Lanes
> that these modules have been pre-loaded?

maybe using the following (untested) generator arguments?

lanes.gen( {required = {"bit", "ffi"}}, func_body)

This tell Lanes to require "bit" and "ffi" in a controlled way that
enables it to grab the module tables and register the functions they
load.
I am almost sure it would solve your problem.

Is it possible to relax the rules
> so that Lanes doesn't kick out when it detects this? If this is possible,
> what is the impact to Lanes and the modules that are pre-loaded before
> Lanes? I might be able to handle additional limitations in my code if Lanes
> can be relaxed.

All this is caused by recursive scanning of the global namespace to
look for existing functions. This scanning constructs a string that
acts as a key to find the function. If the keys are different in
different lua states, the function used to lookup a key in the source
state will yield a key that won't exist in the target state. Therefore
I need to tell lanes where the "official" location for the registered
functions is. Hence the require() patching, "required" generator
argument, and on_state_create configure() callback.

>
> Finally, can you point out in your Lanes code where this check is made (and
> it's aborting)? I'm just trying to understand this better and suspect I have
> a lot to learn.

See above and below (all this is explained in more details the thread
I failed to point you to).

>
> I look forward to your findings. If anyone else has been able to use Lanes
> with LuaJIT2 then I would be very interested in hearing about it (and any
> techniques that had to be employed to get it to work).
>
> Also, it was not apparent to me that the link you suggested
> (http://lua-users.org/lists/lua-l/2011-11/msg00060.html ;) was applicable to
> this problem. Perhaps I'm missing something.

No, it's just that I didn't point to the right thread (which I don't
find using the search facilities of the archive, possibly because my
memory fails me and it was in fact a private mail exchange that I
discarded later on). Anyway, I just wanted to make sure you know about
the on_state_create function that can be passed to lanes.configure.
Maybe this would help solve your problem. But it is rather used in
situations where functions are added to the global namespace like the
base library does.

-- 
Benoit.