Permalink
Switch branches/tags
Nothing to show
Find file
Fetching contributors…
Cannot retrieve contributors at this time
154 lines (123 sloc) 6.13 KB

Concurrent Design

Designing with processes

So I’m going to design an Erlang application. How many processes should I have, and which?

Just as for the question "how many objects should I have", there are many possible answers, …​

I’ve heard that processes are Erlang’s equivalent of objects. Is that true? It sounds a bit wasteful to me.

In principle, you could take an OOP system and make each object into a separate process — but that would be a bad idea for a lot of reasons (performance, memory consumption, maintainability, debuggability, wrong use of a tool).

Everything may be an object, but it takes something to qualify for being a process.

OK — I did think it sounded too simple to be good practise.

Out of curiousity: If I came by an application written in such a fashion — if only partly — how would I be able to detect it?

The tell-tale signs of that approach — beside the abundance of processes, of course — would probably be that many processes had a small, fixed state, and that most of the communication between processes would be synchronous.

Processes should typically by their existence contribute with either concurrency, clarity of code, ownership of resources, or uniformity of interfaces.

I’ve also heard that Erlang is great for parallel computations, because you can cheaply create a new process whenever there’s an opportunity for doing two things in parallel. How about that?

That’s another extreme. Don’t do that either. It’s like saying in OOP that whenever you can use inheritance for reusing code, you should.

Creating a process is cheap compared to other languages, but there’s still a cost — and communicating inputs and results between processes introduces some overhead. So first of all, don’t do it for too small tasks.

And like any other performance optimization which costs in code clarity, don’t do it prematurely. Do it only when you’ve measured that it might be a good idea — and only where your measurements show that it might be worth it. And remember to measure afterwards that the result is in fact a speedup which outweighs the extra complexity.

Okay, enough about extremes; people say so much (especially straw men).

Returning to my question of which processes to have:
You mentioned certain valid /raison d’être/s of processes —  concurrency, clarity of code, ownership of resources, and uniformity of interfaces?

Could you elaborate on these?

Certainly…​
The common theme is separation of concerns.

To take the most concrete first: Some processes are centered around a certain resource; this can be either some data (in normal term form or contained in a table) or a port (file, socket or connection to non-Erlang program).

(TODO)

When can concurrency be a reason for a process to exist?

Using processes for getting concurrency can be done for getting I/O concurrency, CPU concurrency, or scalability.

(TODO)