3 ms·

Lua fully supports scripting in multiple threads i.e. multiple threads can each have a Lua context that runs scripts independent of the other threads. Within a

Lua fully supports scripting in multiple threads i.e. multiple threads can each have a Lua context that runs scripts independent of the other threads. Within a context you can run multiple coroutines but these are all run on the same thread and are cooperative. It doesn't natively support sharing across multiple OS threads.

SwellJoe 9y ago
I was reading the docs for Guile in this regard (https://www.gnu.org/software/guile/manual/html_node/Multi_002dThreading.html https://www.gnu.org/software/guile/manual/html_node/Multi_00...), and even with language support, it seems like you still need to jump through some hoops to do the Right Thing in a multi-threaded program. Seems like in any case, if I were using any of them in a threaded program, I'd want to isolate them from threads as much as possible. One of these days, in my Copious Free Time(tm), I'll take the time to actually look at an implementation to see how people have handled this problem. I wonder if any reasonably complete game engines use Guile, for comparison...
- Johnny_Brahms 9y ago
  The only hoops I can see there is the regular caveats that apply to all parallel programming (don't introduce deadlocks, be careful: other threads might mutate the data you are currently using). That applies only if you are executing guile code in parallel in the same interpreter and environment (or asynchronously accessing interpreter data) which is impossible in insert_other_embeddable_language_here. You don't have to use embedded guile like that. From my experience: if you want to embed a language and only need it in a single thread, it is just as easy to use lua. If you want several interpreters in isolated threads without any communication Lua is easily the simplest solution. But if you need communication between multiple embedded language threads or interpreters you are better of with guile or TCL depending on what threading model you prefer.

SwellJoe 9y ago

I was reading the docs for Guile in this regard (https://www.gnu.org/software/guile/manual/html_node/Multi_002dThreading.html https://www.gnu.org/software/guile/manual/html_node/Multi_00...), and even with language support, it seems like you still need to jump through some hoops to do the Right Thing in a multi-threaded program. Seems like in any case, if I were using any of them in a threaded program, I'd want to isolate them from threads as much as possible. One of these days, in my Copious Free Time(tm), I'll take the time to actually look at an implementation to see how people have handled this problem. I wonder if any reasonably complete game engines use Guile, for comparison...

Johnny_Brahms 9y ago
The only hoops I can see there is the regular caveats that apply to all parallel programming (don't introduce deadlocks, be careful: other threads might mutate the data you are currently using). That applies only if you are executing guile code in parallel in the same interpreter and environment (or asynchronously accessing interpreter data) which is impossible in insert_other_embeddable_language_here. You don't have to use embedded guile like that. From my experience: if you want to embed a language and only need it in a single thread, it is just as easy to use lua. If you want several interpreters in isolated threads without any communication Lua is easily the simplest solution. But if you need communication between multiple embedded language threads or interpreters you are better of with guile or TCL depending on what threading model you prefer.