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 <[email protected]> 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 >> >
