lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


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