[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] llvm-lua 1.0
- From: Alexander Gladysh <agladysh@...>
- Date: Wed, 3 Jun 2009 08:41:07 +0400
>> 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
> 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?