Re: Lua Lanes with package.preload and package.loader

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

2011/11/17 Benoit Germain <bnt.germain@gmail.com>:
>
> Yes. It works with versions 2.x because it transfer function
> references from one lua State to the other by extracting the C
> function pointer from the source function, and creating a C closure in
> the target state using this pointer. I no longer do this ...

Just to clarify things:
When the lane generator is invoked, it copies directly the data (lane
body, associated upvalues, and call parameters) from the caller to the
callee state. Therefore, The 2-way name<->function map must exist in
those 2 states. But whenever data is sent using a linda, there is
another lua state involved, which acts as intermediate storage (called
keeper states). The linda reads and writes in the storage area under
mutex. But this means that the name<->function map must also exist in
the keeper states for non-Lua function references to be mapped
properly. This is managed automatically by Lanes through the hijack of
the require() function at configure() time. When a module is required,
Lanes' require() does 2 things:
- it acts under mutex, just in case the required module isn't
thread-safe, so that multiple concurrent Lanes can require() the
module without having to care about multithreading (at least during
require()).
- it populates the name<->function map in the caller and keeper states

Of course, the name<->function map is populated with the functions
registered by the standard libraries are handled in a similar fashion.

This means that if native functions are registered in a state directly
by the host program without using require(), Lanes can't know about
them, and they can't be transfered because they aren't found in the
function map.

Also, this means that Lanes must be require()d before any module whose
functions you need to transfer in a Lane.

HTH,


-- 
Benoit.