Julia in its present implementation uses a global-interpreter lock much like most other dynamic programming languages, correct?
On Friday, June 20, 2014 10:51:17 AM UTC-4, Stefan Karpinski wrote: > > For concurrent I/O, green threads are far more scalable than using kernel > threads. For concurrent computation, green threads don't buy you anything, > but exposing kernel threads directly as in C++ or Java forces all library > authors to become experts on concurrency since they have to make sure all > of their code is thread-safe, at the very least. Either that or everyone > has to worry about which libraries than can or can't use in concurrent > code. It rapidly becomes a mess. Our current approach to concurrent > computation is a shared-nothing multi-process model that also works across > machines. > > > On Fri, Jun 20, 2014 at 5:57 AM, Tobias Knopp <tobias...@googlemail.com > <javascript:>> wrote: > >> I think the answer to this question is not tight to Julia. Both models >> have advantagous and they are actually not comparable 1 to 1. >> >> One simple reason why Julia currently has no threads is that libjulia is >> not thread safe. I am experimenting in changing this (see >> https://github.com/JuliaLang/julia/pull/6741) but it is far from clear >> if this will be feasible in the end. >> >> Cheers, >> >> Tobi >> >> Am Freitag, 20. Juni 2014 11:32:11 UTC+2 schrieb Bienlein: >> >>> Hello, >>> >>> I'd like to ask why Julia does not have a conventional thread model à la >>> Java, C++, etc. but is based on couroutines. Not that I would criticise >>> this. I would just like to know in what way the use case of Julia promotes >>> couroutines simply out of interest, because it is not obvious to me. >>> >>> Thanks, Bienlein >>> >> >
