Re: Yet another reason to crash with multiple Lua runtime?

[Ross Berteig <Ross@...>]

Sometime on Tue, 15 Jul 2008, Shmuel Zeigerman wrote:
> ....
> I have an app (named lua51x.exe) that is a static build of Lua 
> 5.1 with
> several libraries also linked statically into this executable. 
> So this
> executable has no dependencies other than Windows system libraries
> available on any modern Windows installation, therefore it 
> always works
> "out-of-the-box". However, I'd like it to be able to require()
> additional Lua libraries (that are not built into it).

Although in principle possible, Windows does not support out of 
the box the kind of dynamic linkage required to make this use 
case safe. (Apparently various Unix/linux/bsd-like systems do, 
by noticing that the process already has a required symbol 
exported before attempting to dynamically load a library to 
define it. Windows doesn't do that.)

I suspect that someone really knowledgeable about the details of 
the process loader could create a glue DLL named lua51.dll that 
forwards back to the hosting executable, thus making it possible 
for a require()'d module to link to the one and only copy of the 
Lua core.

> An interesting thing is that Lua 5.1 is almost there. If I don't
> require() 'strict', then lua51x.exe runs happily test suites 
> for all the
> Lua libraries on my system. This makes me think that fixing the
> dummynode_ issue is worthwhile.

As I understand things, the success of the test suite you report 
is by accident, not by design. The other threads on the list 
have talked more authoritatively about what changes would be 
needed in the definition of lua_State to make it more likely to 
work in more cases. But IMHO, that just pushes the can of worms 
a shelf down...

There is already a similar kind of issue involving the C runtime 
library. It is just as critical that every module in the process 
be linked to the same C runtime instance, or you can't expect 
that passing a FILE* around is safe. Mitigating the damage by 
being careful to only free() what you malloc()'d in the right 
runtime DLL helps, but...

For instance, what happens when the loaded module is linked 
against a different version of the lua core than the one 
statically linked into the EXE?  If both the EXE and loaded DLL 
dynamically load and share a single copy of the Lua core DLL, 
then unless one or the other depended on a bug in the older 
version, all is almost certainly well. With a (magical) DLL that 
forwards back to a statically linked core, all is also well. But 
if you share a lua_State between copies of the core then you are 
trusting that all copies have identical definitions of 
lua_State, and that they use them compatibly. That is a pretty 
stiff design requirement to achieve and maintain for not a whole 
lot of benefit.

I would much rather see someone cleverer than I figure out how 
to do the magical forward to the statically linked core.

Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/