There isn't much benefit to running multiple julia instances from one binary, since Julia uses many c libraries, and these have generally not been written with this in mind.
> 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. It might be faster to internally pass around pointer to the TLS in a register, since many functions need to access the GC-frame, so we might still want to do that for a different reason. But the external interface can just pull that information out of TLS, and maintaining thread-local state is not the same as having independent instances in one process. On Fri, Aug 1, 2014 at 9:00 AM, Joseph Naegele <[email protected]> wrote: > 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]> >> 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. >>>> >>> >>
