[erlang-questions] data sharing is outside the semantics of Erlang, but it sure is useful

[Ulf Wiger]

Michael Turner wrote:
> 
> Not sure that I'm totally sold on the Erlang Way of doing things, being
> pretty new to the language.  But in this particular case (or even for
> generalizations of it), I don't see why the Erlang Way (insofar as I
> understand it) is necessarily inferior to anything requiring that the
> language break with its general shared-nothing approach.  Did I miss
> something?

Again, two kinds of sharing here.

'The share-nothing approach' refers to the fact that
there are no shared data structures between processes
(conceptually, as the VM certainly makes use of the
possibility to share stuff anytime it can do so safely.)

The other type of sharing is the implicit sharing /within
an Erlang term/. Consider:

X = lists:seq(1,1000),
Y = {X,X,X,X,X,X,X,X}.

The runtime system will only allocate 2 words for the
tuple + 8 words for the pointers to X. This is
an extremely efficient way of building what's conceptually
a structure of 8000 integers. This is used deliberately by
certain modules. QuickCheck, for example, builds
intricate structures that rely extensively on this type
of sharing. Passing such a structure to another process,
either by spawn or message passing, is generally fatal.

http://erlang.org/pipermail/erlang-bugs/2007-November/000488.html

(This post also contains a nice little program that could
be used to benchmark different solutions.)

I encountered this problem once in a very subtle way,
where I had deliberately relied on implicit sharing
in the state, but happened to pass the entire state
by mistake inside a message.

http://www.erlang.org/pipermail/erlang-questions/2005-November/017924.html

The bug existed for a while, but wasn't noticeable as long
as everything was on the process heap, since the deeply
recursive data structure didn't take up much space.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com