[erlang-questions] A whole bunch of implementation details

Dennis Byrne <>
Fri Sep 5 05:20:45 CEST 2008

Thank you Richard, Mikael and Raimo.  Here's another question I got as a 
follow up.

Can pids be reused, even though the documentation refers to them as 
unique?  Any info on the underlying implementation of how a pid is 
uniquely generated across a cluster?

If they are not unique, what precautions should application developers use 
to guard against this?
Dennis Byrne
ThoughtWorks - Chicago

"Richard A. O'Keefe" <> 
09/04/2008 12:41 AM

Dennis Byrne <>
Re: [erlang-questions] A whole bunch of implementation details

On 4 Sep 2008, at 2:37 pm, Dennis Byrne wrote:
> How does stack memory grow?  Am told Prolog does this dynamically 
> and I was wondering if Erlang did the same.

Some Prologs (DEC-10 Prolog, Quintus Prolog, SICStus Prolog, ...) do 
some Prologs (C Prolog, SWI Prolog) don't.
The Burroughs B6700 used to do this for Algol, BASIC, COBOL, DMAlgol,
ESPOL, FORTRAN, Pascal, and PL/I, back in the late 60s.

"Modern", less capable, systems like say Windows or Unix, do not do this
because they don't know where the pointers are.  The B6700, Prolog 
and Erlang systems, tag each word of memory to say what it is, so you 
infallibly find the pointers.  With that, moving a stack is tedious 
than difficult.

>  Does heap memory contract?

It can.
> Exactly what is the tipping point between what gets passed by value 
> and what gets passed by reference?

There is no pass by reference.  All binaries are passed by value. 
Some binary values are
represented by pointers.  Some of those pointers point to shared 
blocks, some don't.  But
it is still pass by value.  Pass by reference is, by definition, 
passing the address of a
VARIABLE ('var x: t' in Pascal, 't& x' in C++).

Notionally when you send anything in a message, it is copied, 
otherwise it isn't.
Some Erlang systems have had a shared or hybrid heap, in which the 
logical copy is
a no-op.

>  The large binary trick is common knowledge, any other corner cases?
> How does the VM differentiate between a node that is temporarily 
> unresponsive and one that is down?  In other words, at what point 
> does a node give up on a peer?

There is no infallible way to tell.  Mistakes will always be made.
The net_kernel module sets up a "ticker" process that periodically
sends a message to every node it's in communication with; if it
doesn't hear from a node after a while it assumes it's down.
If a node is shut down in an orderly way it will tell is peers
that it is going down.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080904/3702454f/attachment.html>

More information about the erlang-questions mailing list