[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] llvm-lua 1.0
- From: Alexander Gladysh <agladysh@...>
- Date: Fri, 5 Jun 2009 20:05:46 +0400
On Thu, Jun 4, 2009 at 11:30 AM, Robert G. Jakabosky
> On Tuesday 02, Alexander Gladysh wrote:
>> >> 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.
> I hope you don't mind trying out the latest revision of llvm-lua from the
> subversion repository. Just committed a thread-safe version. Now
> each "lua_State" instance has it's own LLVMCompiler & LLVM JIT engine
> Also llvm-lua can now be easily compiled with C++ exception support (i.e. with
> try/catch instead of setjmp/longjmp).
> just use this command to compile:
> make linux LUA_CPP_SUPPORT=1
> The new code passes all my test scripts. I haven't tried catching the Lua
> generated errors in C++ code that wraps/calls Lua code, but pcall can catch
> exceptions generated by error().
Wow, thanks! I will try it as soon as I can. Unfortunately it would be
sometime next week. :-(
We use Lua built as .so. Is this fine with llvm-lua?
>> > 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.
Perhaps it is better to be left configurable -- there are probably
uses for either of options.
>> Thanks. I will eagerly wait for thread-safe llvm-lua. Can you give any
>> clues on when it could be released?
> If you can test the lastest code to help verify that these new feature work,
> then I will roll a new release.