Is LuaDist´s lua-5.1.5 liblua.dll multhithreading compatible?

[Helmut Gruber]

Is it?
Helmut

[Peter Drahoš]

On Tue, Jun 17, 2014 at 7:49 PM, Helmut Gruber <hgr...@gmx.net> wrote:
> Is it?
> Helmut
>
Hello Helmut,
LuaDist uses vanilla lua with only the build system and module loading
modified. There are no other modifications applied. The question comes
up quite often so there is a wiki page for it[1].

pd

[1] http://lua-users.org/wiki/ThreadsTutorial

[Thijs Schreijer]

Not sure if this is what the OP meant; iirc in Visual Studio when building dlls, one has the option to build multithreaded capable dlls. I think those became the standard (2008 onwards? Not sure though). So I suspect this is what the OP wanted to know.

Thijs

[Peter Drahoš]

I see,
that would make more sense. if Helmut means thread safe exception handling (mingw "-mthreads" flag) then the answer is no. I am not entirely sure it is needed when using MinGW with posix threads.

pd

[Helmut Gruber]

Sorry for this ambiguous question.
My concern is: when I use liblua.dll in a multithreaded C/C++ application, or even one of the llthread/llthread2 modules with Lua itself, and each thread spawns a new Lua state, with it´s own set of modules - are there any known implications to be aware of?
This is not so much a Lua-ish question, it´s more about the C runtime environment that is being used: MSVCR.dll...

[Peter Drahoš]

On 17 Jun, 2014, at 23:13 , Helmut Gruber <hgr...@gmx.net> wrote:

> Sorry for this ambiguous question.
> My concern is: when I use liblua.dll in a multithreaded C/C++ application, or even one of the llthread/llthread2 modules with Lua itself, and each thread spawns a new Lua state, with it´s own set of modules - are there any known implications to be aware of?
> This is not so much a Lua-ish question, it´s more about the C runtime environment that is being used: MSVCR.dll...

Not a MSVC expert,
however there are no issues with the MinGW built binaries that I know of in that context. I can add an MSVC specific threadsafe option that links in the thread library but I have no way of testing that it has any effect on thread safety in Visual Studio.

As usual, test cases and patches are welcome if you find any problems with the build.

pd