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

On Apr 3, 2007, at 8:52 AM, Asko Kauppi wrote:

If we turn the case upside-down, and think "what if" PRIVATE flag was not used in Lua core.

o Multiple process, multiple Lua states:
no effect (having their memory areas completely separate)

o Single process, single Lua state:
no effects?
what if two modules have the same global variable name? does someone know what happens?

It'll still be separate variables. If they're declared 'static' they're not available to the dynamic loader anyway, so a Lua module that exports exactly one global name does not have to worry. Dynamically loaded modules don't pollute the namespace of other modules by default. This is by design, because these modules often have routine with fixed names (e.g. ODBC database interface modules).

o Single process, multiple states (multicore case):
globals in a module would share addresses, thus being able to do "inter-state" communications (if needed)
Thread Local Storage can be used, in case modules like to keep things private (but need to explicitly do so)
also "static" keywords seems to imply by-thread behaviour, but I wouldn't trust that much

'static' does not imply by-thread behaviour. 'static' only makes the object invisible to other modules. The PRIVATE flag loads the complete module a second time at a different address. If you leave it out the loader uses handle reference counting and loads the module only once. That's pretty much all there is to it. So if each thread loads its own copy you get the equivalent of thread local storage, but it's not really related to theads, it's because of wholesale copying of modules, which can be expensive if you run lots of threads. Use position independent code if you do that, otherwise you'll use lots of memory.

So, should I bang my head, make a <100% safe hack, or just call this a quit and try to lobby for ditching PRIVATE in Lua in >= 5.2 ?

Might as well lobby to make using 'dlopen' the default for Mac OS X, so the behavior is the same across all OSes. (You can share variables between processes in Windows, but I won't go there). Assuming OS X 10.2.x is outdated by now there's no pressing reason to keep using a separate dynamic loader implementation for OS X.

And.. are other systems affected? If they don't have the concept of dll/so-private globals, there's not much benefit having OS X ask for it?

Windows can do special tricks as well, but AFAIK the Unix-type systems don't offer anything special, and you have to use Posix threads functionality for thread-local storage. For code designed to be portable within the Posix family the use of the 'PRIVATE' flag is an impediment to portability. For that reason alone it needs to be removed.

Gé