Yeah, I think Guile has basically been a failure on that front. I didn't want to be harsh, as it seems to be a well-maintained project by smart people...but, as extension languages go, it sure isn't doing much extending in the real world.
Guile does this with bravura.
This avoids the Global Interpreter Lock problem that plagues Python. How does Guile handle that?
If you don't cross the C barrier again from your scheme code you can even use something like guile-fibers for Concurrent ML-like parallelism.
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.
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...
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.