Re: [ANN] llvm-lua 1.0

[Alexander Gladysh <agladysh@...>]

>> 2. We have many Lua states created and used in many threads (one state
>> is used by a single thread at a time). Would this work with llvm-lua?

> Not the current release.  The LLVMCompiler class is not thread-safe and one
> instance of that class is stored in a global variable.

This is the show stopper then.

> The only use of that
> instance is in llvm-lua/llvm_compiler.cpp, and it could be protected with a
> lock or maybe converted to a thread-local variable.  The llvm_compiler.cpp
> file is just a C wrapper around the C++ class to make it easier for the Lua
> core to call the compiler, it is only about 70 lines.  Unless you have >100
> threads with all of them loading new Lua code all the time, a lock shouldn't
> cause a bottleneck.

My Lua code is usually cached, but at the start of the server it is
intensely loaded. Have to try it on actual code to get the real
picture though.

> Right now that one instance of LLVMCompiler is shared by all lua_States, I
> might move the global variable to a member variable of 'lua_State' .  A lock
> on that shared instance might still be the best option.  I will look into
> this for the next release.

Thanks. I will eagerly wait for thread-safe llvm-lua. Can you give any
clues on when it could be released?

Alexander.