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. >> >
