Hacker News Reader

Comment by smaili | Hacker News Reader

Could someone explain how in the context of the article, "process" differs from a "thread", in say Java or Python? Or are they one in the same?

View on HN

Process is the correct term. It denotes a unit of execution with an independent memory space, just like an OS process. However, instead of using OS processes and relying on the OS scheduler, the Erlang VM has its own scheduler and manages its own processes. Those processes are incredibly small. 100k erlang processes consume just a few hundred MB of memory.

So it is like go routine?

Yes. In fact go routines and channels are touted as an implementation of Tony Hoare's CSP -- Communicating Sequential Processes.

Somewhat, except goroutines have shared memory and the tradeoffs that come from that.

Also, much better tooling around Erlang processes than goroutines.

In Erlang, a "process" is analogous to a Java or Python thread in that it's not spinning up a separate OS-level process, but it really functions as its own self-contained process within the Erlang VM. Processes communicate with messages (like OS-level processes) but can't directly share state (like threads would). The result is that in a single Erlang VM, you can have a butt-ton of processes, each effectively runs a full copy of whatever it needs to run, and it can fail, crash, or otherwise explode without affecting the other processes in the VM. The model is what gives Erlang its remarkable resilience and scalability.

An Erlang process isn't really equivalent to a Java thread. A Java thread maps to a native thread, whereas an Erlang process is entirely in userspace. Erlang processes are basically green threads without shared state. Java has no equivalent in the standard library.

It's not equivalent, but it's roughly analogous from the Java programmer's perspective. You would spawn a new process much like you would start a new thread, but the similarities end there.

"Whenever you would spawn a new thread in Java, you would spawn a process." While that is true, it represents a subset of cases where you would spawn a process.

Processes are meant to model the real world. I'd say the truth is closer to "Any time you would instantiate an object in Java, you spawn a process." That's not always going to be true, but more true than you might expect.

It is really something different. Depends on what axes you are comparing. It is analogous in one aspect -- a unit of execution. But is very different in that it doesn't share memory. That second part is crucial and it what makes it have better reliability, better GC characteristics and so on.

All interesting replies, but as I am not an erlang programmer could someone briefly explain the threading model? Whatever the unit of code packaging is ultimately it all has to get scheduled onto a core. On what platform is 2,000,000 threads a realistic scenario? If you don't have 2,000,000 threads you don't have 2,000,000 web servers. You might, for example, have 2000 web servers each using an event-driven framework to handle 1000 concurrent requests. Is that closer to the erlang processing model?

A single preemptive event driven framework is probably a closer match.

BEAM has a very efficient multi core fair scheduler. All 2M process share time on all available cores and are handled by a single scheduler. Because it's preemptive, starvation problems one might see on an event loop are avoided. A CPU intensive process can run alongside low latency IO processes and they are all fairly scheduled.

As others have said, Erlang processes are not OS processes, nor are they Java threads. They're closer to Go's goroutines or Python's eventlets; they are well-suited to run even a single function concurrently.

In the analogy, it's like having 2M web servers, but where only, say, 1000 of them are actually running. As a developer having independent web servers helps you to think about what should be done instead of how it's going to be done. After that, the fact that a server is actually running or it is stalled because it's reading from disk or it is waiting for available CPU is an implementation detail and something that monitoring will show you.

The erlang process model, since SMP support is more or less, each cpu core runs one OS thread which is running a 'scheduler'. Each scheduler has a list of processes, and determines the order they should get to run in; the currently scheduled process is run in the scheduler's thread, until it has used its quota of cpu (reductions) or it hits some other trigger that causes its execution to be suspended (waiting for a message, sending a message to a busy port, maybe some other cases?). Schedulers have a method to balance their work queues, etc. (Leaving out dirty schedulers, io schedulers, configuration of schedulers etc)

Each erlang process has its own (erlang) heap and stack, and there is no ability within the Erlang language to access memory by address, a process will only access its own memory, or special types of shared memory (such as the shared/large binary heap).

From the OS perspective, it's one process, with one memory space, and several threads.

A realistic Erlang example where you would have 2 Million processes is something like a chat server (1 process per connected user), either via a traditional tcp protocol or a websocket protocol for a browser. In another language, you would likely need to multiplex multiple users onto each thread, in Erlang each user gets their own process and the code ends up being quite straight forward.

Generally, processes do not share memory, but threads may.

The main difference between a thread and an Erlang actor is that with threads you have to manage resource sharing with locks and with actors you don't share resources. Instead you pass the needed data to each actor through messages. The end result is that it's way easier to manage concurrency through actors rather than threads. It also buys you more features; imagine being able to access all of the actors of a cluster of machines or determining what to do when an actor fails (eg restart it or fail all other actors under the same actor supervisor). I feel that the closest thing to the actor model in the thread world is probably Java's Executor (minus the cool features)

You can do actor model concurrency on Java (and Scala) with the Akka framework (http://http://akka.io). It's a pretty mature one as well. I've been using it for a while now.

Threads share heap memory. Processes don't.

Erlang processes are very lightweight (only a few KB of memory) yet they have the property of OS processes of keeping their data isolated.

Think about it like an operating system. In most programming platforms today you are essentially programming in Windows 3.1 or DOS. So when the calculator process crashes, it could take down your game or your word processor because they all share their memory space. That is all cool, but it is cool for 1994, not for 2016.

When programming in Elixir/Erlang/LFE, is like moving up the ladder and using a real OS (preemptable execution, processes don't mess with each other's memory, and so on).

Reply on news.ycombinator.com