3 ms·

>> What about multiple interpreters? > > Like arenas? Guile doesn't do this, no. I've never > understood the desire for this, either; if you want to > i

>> What about multiple interpreters? > > Like arenas? Guile doesn't do this, no. I've never > understood the desire for this, either; if you want to > isolate users, put them in different modules. I think he means running two interpreters in the same address space and/or thread. In Lua, a pointer to the entire interpreter state is passed around in a ``lua_State * ``, so it's easy to embed without worrying about one interpreter accidentally mucking with another. I believe Python does something similar with ``PyInterpreterState * ``. Based on the Guile API reference[1], it's not possible to safely run two Guile interpreters in the same pthread. This makes it difficult to embed in languages with alternative threading models. [1] http://www.gnu.org/software/guile/manual/html_node/Initialization.html#Initialization http://www.gnu.org/software/guile/manual/html_node/Initializ...

oddthink 16y ago
Yes, that's it exactly. I've grown more and more averse to implicit state. I like that in Lua, all my interactions with the interpreter are mediated by the lua_State. If I want to run two at once, I can. If I want to store a Lua object for later use, I can stash it in there. If I want to have a globally-available state for my programs, I can implement it myself as a global. Nothing is mucking around with the call stack looking for things that "look like a pointer." A few years ago, I wanted to embed a scripting language into a monster of a multithreaded C++ application, which (oh joy) was using RogueWave threads rather than straight pthreads. I tried python, but couldn't figure out how to get the thread locking to work properly; python had its own ideas about how the threading should work. Then, I tried Lua. With Lua, I could just implement a pool of properly-initialized interpreters, then assign them out to each thread on need. It worked very well.
gaius 16y ago
Tcl also does this I believe.

oddthink 16y ago

Yes, that's it exactly. I've grown more and more averse to implicit state. I like that in Lua, all my interactions with the interpreter are mediated by the lua_State. If I want to run two at once, I can. If I want to store a Lua object for later use, I can stash it in there. If I want to have a globally-available state for my programs, I can implement it myself as a global. Nothing is mucking around with the call stack looking for things that "look like a pointer." A few years ago, I wanted to embed a scripting language into a monster of a multithreaded C++ application, which (oh joy) was using RogueWave threads rather than straight pthreads. I tried python, but couldn't figure out how to get the thread locking to work properly; python had its own ideas about how the threading should work. Then, I tried Lua. With Lua, I could just implement a pool of properly-initialized interpreters, then assign them out to each thread on need. It worked very well.

gaius 16y ago

Tcl also does this I believe.