 |
lua-l archive |
|
|
||
|
Thanks for a good description of the issue.So, I take it that the PRIVATE behaviour is expected, "by design" and not by chance. It kind of does make sense, since privacy is always good, and using separate states has been a marginal issue. WIth multicore processors, this may change, though.
Some points:- is this behaviour consistent over architectures (Linux, Windows, ...) - is it documented, because it sure is an important point for module craftsmen
I may need to use named shared memory, or something, to actually get the module instances know each other. Given that the PRIVATE behaviour is there to stay. It may still be best to have it like this, requiring people who want the instances to know each other to take the extra steps. We may need a wiki page on this?
-askops. in order to be at the same addresses, the variables need to be global (not static) even if the PRIVATE flag is not there. This would give a neat way of balancing between the two "modes" but maybe it's too subtle, and a gcc upgrade would blow it off, some day? :)
Jerome Vuarand kirjoitti 2.4.2007 kello 23:10:
Sam Roberts wrote:On Mon, Apr 02, 2007 at 09:49:56PM +0300, Asko Kauppi wrote:Lua uses NSLINKMODULE_OPTION_PRIVATE flag on OS X for its "require", but this causes globals in a module required in two separate Lua states NOT to have common globals. I faced this today, and the only solution found was removing that flag from loadlib.c.As a quick fix, have you tried using dlopen() instead? It is recommended on OS X (by Apple, see http://lua-users.org/wiki/BuildingLua). Still, I'm a little surprised that the bundle was loaded twice. Could this be a bug? Isn't package supposed to load the bundle/so/dll only the first time the module is required, and the other times to use the previously opened shared library handle, find the luaopen_XX symbol using that handle, and call it again in the new state? The package module definitely keeps the load handle around, I don't see why it shouldn't use it!The problem comes from the fact that Asko use separate Lua states. If abinary module is required in two independents Lua states, it's initialization function must be called twice. Since binary modules may not be reentrant and use globals to store "Lua-state"-specific information, having it loaded twice with private static data allows to avoid collisions in memory between the two instances of the module, while the package system still ensure that all require in the same Lua state will always return the same module table. If you make the static data shared (by removing the aforementioned flag), to allow communication between the two instances of the module, you have to make sure all binary modules you load don't store "Lua-state"-specific information in static variables. For example you can't store registry indices in globals and share them between Lua states, since each has its own registry.