[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Yet another reason to crash with multiple Lua runtime?
- From: askok@...
- Date: Tue, 15 Jul 2008 20:54:36 +0300
I think there's a better way to solve that issue, and yes,
this has been on the list before.
Windows exe's can expose their functions to the dll's, so
you really don't need the dll's to rely on a lua51.dll.
You'll use the core which is in Lua 5.1.
What would be beneficial, though, would be a way to detect
this kind of situations and give an error instead of
seemingly working. Each OS is different in this area, and
allowing for multiple cores would mean a _lot_ of extra
testing. Surely not worth it. I.e. OS X is otherwise fine,
but not when multiple Lua states are being used. The
errors one gets are rather awkward (yet another reason to
have Lua autodetect the multiple engines issue?).
But I don't see a way how it could be detected from within
the program, in a portable manner.
On Tue, 15 Jul 2008 16:25:43 +0300
Shmuel Zeigerman <firstname.lastname@example.org> wrote:
Luiz Henrique de Figueiredo wrote:
This is well known and has been mentioned in the
archives. The answer of
course is make sure not to link more than one Lua core
into your app!
Though I won't argue with the above statement, there's a
case when it'd be desirable to be able to have 2 Lua
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).
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