[erlang-questions] Erlang info

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Tue Jun 12 21:16:48 CEST 2018

On Tue, Jun 12, 2018 at 9:00 PM joe mcguckin <joe@REDACTED> wrote:

> If it was a voice switch, surely they must have used C (or similar) to
> perform the low-level hardware interfacing stuff like voice transcoding,
> digitization, etc
Chances are C is too slow for this operation as well. You usually need
either FPGAs or ASICs and then a (thin) C driver layer to interface with
the Erlang Control Plane. But I have relatively little knowledge of the
actual Ericsson projects and their inner workings.

> How easy is it for a  task to fire off a new thread on a different server?

Starting a new process on another Erlang node is rather easy. Calling eg,
spawn(Node, Fun) will start running Fun on the node Node (which is usually
on a different machine).

However, in most systems which need this, you tend to build higher-level
solutions out of the underlying primitives depending on what kind of
fault-guarantees you are looking for and what kind of problem you are
trying to solve. Because working at the lowest level requires a lot of
attention to the small details which you would like to solve once and for

The reason we tend to say process and not thread is because threads usually
implies there is a shared data space all threads can access with locks
around data so shared. First, this model is going to break down in a
distributed setting (Unless you have direct DMA over the network in a
HPC-setting). Second, an Erlang process logically do not share data with
each other and owns its own data. The current implementation is very
explicit about this, giving each process its own heap, stack and garbage
collection. But one could imagine sharing the heap among all processes:
because the language is functional, there is no way one process can
overwrite the data of another.

The biggest secret is that data is copied between processes, and usually
not passed by reference (except a few types of data). Since messages are
often small and since this improves data locality (especially when you are
distributed), the overhead of doing so tend to be smaller than what people
think it is. This also suggests a model where you tend to move the
computation to where the data is, rather than moving the data to the
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180612/9d964db1/attachment.htm>

More information about the erlang-questions mailing list