Re: [ANN] llvm-lua 1.0

[Alexander Gladysh <agladysh@...>]

On Thu, Jun 4, 2009 at 11:30 AM, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
> 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
> instance.

> 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.

Alexander.