Re: [ANNOUNCE] Lua 5.0 (pre-release) now available

[Jean-Claude Wippler <jcw@...>]

Roberto Ierusalimschy wrote:

> In Windows, blocks created by a dll cannot be free in a different dll
> (is that right?), even if both dlls contain exactly the same code.
>
> So, to avoid problems in Windows, the "correct" way to use loaded
> objects is to make Lua itself a dll loaded by the main program,
> so that the main program, Lua, and any extra module all share a single
> copy of Lua.

The problem is global data.  The C runtime has globals, such as to 
track the free space arena.  If you link the C runtime statically to 
the exe (which is an option), and dynamically to a DLL (which is always 
the case, AFAIK), then you end up with two free space managers.  
Freeing a block allocated from one in the other causes trouble.

The solution is to always link the C runtime dynamically (i.e. against 
MSVCRT.DLL), also in the main exe.  Then, the same arene gets used for 
all allocations.  There can be more globals which cause trouble 
(strftime used to be a trouble spot, IIRC).

Lua itself could be linked in statically, even on Windows AFAIK (but 
they still need to have dllexport, and you still need an import lib).  
On most Unix systems that also works (that's what -E / -export-dynamic 
is about).  This is called "back-linking", i.e. a shared lib will 
resolve against what is already loaded.  It doesn't work on all 
systems, and even on Windows I understand that it's tricky to get this 
right.  With shared libs which are loaded at run time, this is 
controlled by the RTLD_GLOBAL flag on Unix.

So the easiest way out is to put common code such as Lua in a shared 
lib, and have both the main exe and all shared libs which do lua_* 
calls linked to it dynamically.  Here's an old picture:
	http://www.equi4.com/old/extuse1.gif

It all works fine that way (as Python has proven for years: Python 
builds as a shared lib on Windows, and as an exe on systems such as 
Linux, Solaris, etc).  Not sure about AIX.

But it remains tricky.  The other approach is a COM-like dispatch as in 
Tcl >= 8.1: set up a call vector and pass it to the called shared lib, 
which then issues calls *back* into the main app.  It requires a lot of 
footwork to make this work (Tcl's "stubs", which re-routes all Tcl_* 
calls via a bunch of generated #define's), but it completely resolves 
all such issues.  It simplifies extensions greatly, because they need 
not be linked to any particular version/location of (in this case) a 
lua shared lib and can continue to work with newer releases.  In 
essence, the calling party hands over a jump vector to the shared lib 
with *all* the calls it can do (i.e. lua_* calls).  No need for shared 
lua libs, nor even for LD_LIBRARY_PATH, since the shared lib no longer 
has unresolved externals (other than the standard C runtime).

-jcw