Re: Is Lua the next big thing?

[Johann Hibschman <johannh@...>]

Grellier, Thierry wrote:
> We are running C++ applications with both Lua an Python embedded. 
> Lua was initially attractive to replace the configuration text file we
> were using. Then we wanted to define through script the behavior of some
> C++ application threads (note this are not real threads but coroutines).
>   
That's funny.  I've been experimenting with Lua over Python just because 
of python's global interpreter lock; using Python would limit me to 
having just one active OS thread.  I was all set to emphasize this point 
more when I noticed that your threads "are not real threads but 
coroutines".  Good thing I checked.  :-)

> We haven't seen an easy solution with Lua:
> despite it offers coroutines, it doesn't allow to redefine lua_yield()
> to have an external control on the lua_resume(). So we were not
> confident in having C++ yields combined with lua_resume().
>   

I thought people were doing this all the time with Lua, but I've not 
done it myself.  Is it really this tricky?
> Whereas Python creates a state but offer low level primitives to store
> the interpreter state and restore it with a python context switch.
> Once python is embedded, this is not any more a pain to embed it.
Would it be possible to graft these primitives onto Lua?
> I guess that dealing with threads isn't an uncommon. With question like:
> should I create one lua_State per C++-threads (then isolated, and only
> sharing the C++ layer).
> or share one lua_State between my C++threads, but then I must let the
> interpreter schedule them.
> or use pure lua coroutine but only lua can schedule the system.
>   
Aha.  See, now you're talking about real OS threads.  Here, it seems 
like Lua is the clear winner, due to Python's GIL.  I have a pool of 
worker threads, each with its own lua_State, and this works pretty well. 
Now, I don't need much in the way of inter-thread communication; most of 
the communication is of the "here, now do this, and give me back the 
answer when you're done" variety.

On, say, an 8-core linux box, using OS threads runs a lot faster than a 
single thread with coroutines would.
> So when like us we need to share one lua_state between C++ threads, but
> with giving to the lua code the possibility to call a C++ wait() and not
> lua_yield(), we are in trouble. And python can here fill the gap.
>   
I still find this a little surprising, though.  Why can't you just use 
yield on this?

-Johann