On Apr 3, 2007, at 8:52 AM, Asko Kauppi wrote:
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).
'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.
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.
I compile Lua with the -DLUA_USE_LINUX flag (which requires the '-lreadline' library). To support Mac OS X 10.3 you could use -DLUA_USE_POSIX -DLUA_USE_DLOPEN, and you'll get the behavior you want.
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.