[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Is Lua the next big thing?
- From: Johann Hibschman <johannh@...>
- Date: Sat, 10 Mar 2007 10:48:20 -0500
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
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. :-)
were using. Then we wanted to define through script the behavior of some
C++ application threads (note this are not real threads but coroutines).
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?
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.
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.
On, say, an 8-core linux box, using OS threads runs a lot faster than a
single thread with coroutines would.
I still find this a little surprising, though. Why can't you just use
yield on this?
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.