Re: LuaLanes 3.1.0 and LuaJIT 2.0.0-beta9 Problem

[Glenn Schmottlach <gschmottlach@...>]

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.

Can you give me more details (e.g. a small code segment) that illustrates how to use on_state_create function in the call the configure. I'm a bit of a noob here and any help would be appreciated. Also, if you run across the thread discussing the on_state_create function it would be appreciated.

Thanks for the continued support . . .

On Tue, Apr 24, 2012 at 10:11 AM, Benoit Germain <bnt.germain@gmail.com> wrote:

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.