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

[askok@...]

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.

-asko


On Tue, 15 Jul 2008 16:25:43 +0300
 Shmuel Zeigerman <shmuz@bezeqint.net> 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 
> cores.
>
> 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 
> worthwhile.
>
> --
> Shmuel