Re: NSLINKMODULE_OPTION_PRIVATE a problem? (OS X require of a modulemultiple times)

[Rici Lake <lua@...>]

Sam Roberts wrote:
> Ok, that explains why you can't call luaopen_XXX twice, that makes
> sense, they aren't written to be called multiple times, often.

They should be, though.
> But, it still does not make sense to me that require() reloads a module,
> possibly, depending on the state. This seems like standing on quicksand.

It has to. Different (master) lua_States are completely isolated
from each other; they use no mutable globals, and they can therefore
be used in a multithreaded application without worrying about
synchronization. Two different extension libraries, for example,
can both use Lua without anyone having to worry about interactions
between them. I think that's good design.

This doesn't apply to lua_States created with lua_newthread().
require() is global to a master state, so threads which call
require() will not trigger a second dynamic module load.

> Does this means that the only safe way to use a binary module is to
> require it once, before any coroutines are created, because if require()
> is called from within a coroutine, it will always create another copy
> of the module?

No, only if you use more than one master lua_State (see above).

> > 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.
>
> They do? So if cfunctions from my binary modules are called from a
> coroutine(a different lua_State, right?), and they try and check the
> type of a userdata by looking up it's metatable in "the" registry, they
> will not find it?

Again, that's an issue of having two unrelated lua_States. The registry
(unlike the thread environment) is global.

Some people do like to use mutable globals in their applications, and
sometimes it's unavoidable because some popular libraries use mutable
globals. However, storing registry indices in a global variable and
then using more than one unrelated lua_State is a recipe for disaster.

There is an unrelated issue with the use of the address of a global
static structure in ltable.c. I think that ought to get fixed.

Rici