This is how Lua enables reentrancy and it's generally not considered a nightmare. We are also talking about two different issues. One is allowing Julia to run code in multiple threads using one runtime, GC, etc. which I'm sure is relatively high priority for you guys. The other issue is of the ability to run multiple Julia "instances" in one binary. From a high-level perspective Julia operates just like an interpreter, but it currently suffers from the same issue as Python in that you can only embed one interpreter instance in a running process. Lua solves this by simply requiring all interpreter state to be passed by the client code to all Lua API functions. It's a pretty common paradigm.
On Tuesday, July 29, 2014 1:31:05 PM UTC-4, Stefan Karpinski wrote: > > It will be a combination of global state with appropriate locks and > thread-local storage. Passing around a global struct is not going to be the > interface since that tends to make interaction with C libraries and such a > nightmare because you need to somehow thread that extra bit of data through > all function calls. Using thread-local storage avoids that problem. > > > On Tue, Jul 29, 2014 at 1:02 PM, Joseph Naegele <[email protected] > <javascript:>> wrote: > >> Great thanks for the clarification. I guess I should have ascertained >> that it is not reentrant since the C-API obviously modifies some global >> state. >> I will look at the current development for threading support for fun but >> in the meantime, will the implementation always modify global state or will >> the C-API pass around a state structure, allowing for multiple embedded >> instances? >> >> On Tuesday, July 29, 2014 12:40:05 PM UTC-4, Stefan Karpinski wrote: >> >>> On Tue, Jul 29, 2014 at 12:33 PM, Joseph Naegele <[email protected]> >>> wrote: >>> >>>> Is it safe to allow code in multiple threads access the Julia runtime >>>> using the C-API? >>> >>> >>> It is currently not safe – Julia is not reentrant. This will change when >>> we add threading support (already in progress), but even then, it's not yet >>> clear if it will be possible to just arbitrarily call Julia code from C++ >>> threads. There's a lot of crazy things that need to be done to make >>> threading work reliably and conveniently, especially in the presence of >>> garbage collection, which will need stop all threads by signalling them so >>> that it can mark and sweep while nothing is being changed. >>> >> >
