[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Yet another reason to crash with multiple Lua runtime?
- From: Ross Berteig <Ross@...>
- Date: Tue, 15 Jul 2008 13:47:21 -0700
Sometime on Tue, 15 Jul 2008, Shmuel Zeigerman wrote:
I have an app (named lua51x.exe) that is a static build of Lua
several libraries also linked statically into this executable.
executable has no dependencies other than Windows system libraries
available on any modern Windows installation, therefore it
"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
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/