Tony Arcieri wrote in post #1067845:
> Erlang used to be green threaded, however with the introduction of the
> scheduler in R12B Erlang gained native thread/multicore support and
> processes began to run in parallel.
> You are colluding terms and that is what is making the discussion
I am using the terms I see in the literature, and in the links provided
to you above. I am using the terms in the same way the links provided
use the terms.
I have not seen any literature say that Erlang is no longer green
threaded (er, green processed). In fact I was just reading more stuff
today that referred to Erlang as having green processes. Erlang's own
docs say that it has green processes.
I am reading Erlang documentation right now which which states that an
Erlang process doesn't amount to much more than a pointer within the
Erlang VM pointing off to some chunk of code/memory inside the Erlang
VM, which explains why the processes are so lightweight.
Again, it doesn't say it's a pointer pointing off to something OUTSIDE
THE VM. Rather, it points to something WITHIN IT.
Again I say I can spawn off several hundred thousand in a second with my
crappy notebook (I can't do that with pthreads, kernel threads, OS
threads, whatever). Again I say I can have literally millions of the
things running (latest version of Erlang). And while doing this, I can
bring up the OS process viewer, and also view the threads running within
the processes. Guess what? NOTHING CHANGES. There aren't thousands or
millions of new processes or threads being added to the OS. There's the
same processes/threads that were there before. In other words, the OS
doesn't know about any of these new processes I fired off within Erlang,
and it isn't creating new threads to handle them. But I can bring up a
process viewer within Erlang, and the millions of processes I created
are all right there.
The fact that the Erlang VM can now take advantage of multiple cores and
move these green processes (which are sparked within the VM and live
within the VM) between the cores by moving them between VMs running one
per core (one OS thread per core is the recommended approach) doesn't
mean the processes aren't green. Just because they can now actually run
truly in parallel (because they are running on different VMs which are
running on different cores) doesn't mean they aren't green.
Can we agree that my Erlang code (compiled to Erlang VM bytecode) has to
be run within an Erlang VM (I'm not compiling it to native code)? If
so, then it means that if some kind of OS or kernel thread was used to
model Erlang processes, an Erlang VM would have to be fired up for each
kernel thread to execute my code. You are talking hundreds of thousands
of VMs being created per second, and millions running on the system. Of
course that doesn't happen.
Erlang didn't change the processes. It didn't change the threading. It
added a scheduler and the infrastructure to allow the green processes
living within the VM to be scheduled across VMs running on other cores.
Erlang's own docs recommend running only one VM in a single thread per
core, because it says you aren't going to get any speedup if you add
more threads and more VMs per core.
> Sorry to get pedantic, but the term "green threads" was termed
> to distinguish the threading models of systems that don't use native
> threads from ones which do (i.e. the opposite of "green threaded" is
> "native threaded").
All systems have always used native threads at some point - otherwise
the systems couldn't run at all. At the end of the day, there has
always been and always will be a native thread running somewhere. So
the term "green threaded" doesn't distinguish between systems which
don't use native threads from ones which do, because at the end of the
day they all do. The term "green threaded" (or in Erlang's case, "green
processed") refers to whether or not and how virtual threads or
processes being created and living in the VM map to 'real threads' in
Therefore, if you have a system that spawns one 'real thread' (call it a
kernel thread, a pthread, whatever) on the OS for each thread that is
spawned in the VM, then it is not green threaded - the threads are OS
threads. If you have a system that spawns no 'real threads' on the OS
for any threads created in the VM, you have a green threaded system.
> As soon as you have parallel OS threads (i.e. on a
> multicore computer) managing the scheduling of multiple userspace
> threads/"microthreads", you no longer have a "green threaded" system,
> have one which is using native threads.
That's entirely incorrect, because you could have one thread running on
each core, with a single GREEN-THREADED VM running on each of those
threads (x cores, x threads total, x VMs running total). This is what
Erlang does now. The only thing different now than in the past is that
the VMs will communicate back and forth and schedule their GREEN THREADS
across each other.
Posted via http://www.ruby-forum.com/.