Meyer, OO and concurrency

David Hopwood <>
Sun Jul 17 01:26:25 CEST 2005

Ulf Wiger wrote:
> Den 2005-07-15 01:44:14 skrev David Hopwood  
> <>:
>> I think there may be some misunderstandings in this thread about what
>> process GC in actor systems is intended to achieve. As for any kind
>> of value in any GC algorithm, processes are only collected based on
>> a conservative approximation of whether they can affect the future
>> behaviour of the program. It is quite possible to have processes that
>> cannot do anything useful but that are still reachable; these are not
>> collected. But this is really no different from any other kind of
>> memory leak that can occur despite the use of precise GC, and is in
>> practice easily avoidable.
> Since you're talking about the actor model specifically,
> and state that some issues are only problems if you try
> to implement OO in the actor model, I thought I'd try to
> read about the actor model. I found this page:
> I read "Towards a Theory of Actor Computation" by Agha et al.

That's probably not the best paper to start with. Try sections
I--IX of /Actors and Continuous Functionals/, or if you have time,
read Agha's book (

(All papers I mention in this post are available from

> The hour is late, so perhaps my reading was too sloppy. I
> didn't really see how the message reception semantics were
> defined. The paper talks about data channels (which are not
> present in Erlang), and specifically disallows passing
> lambda expressions in a message to an actor.

That restriction is specific to that paper, and highly atypical of
actor languages in general. There is an equivalence between actors
and lambda abstractions, and so no need to introduce lambda
abstractions as a separate concept in actor languages. I think the
paper did it that way in order for the kernel language it is defining
to be a strict extension of the lambda calculus.

> This is allowed
> in Erlang. From my first read, I assume that the reception
> semantics are FIFO, event-based, much like in CSP, and not
> selective receive a la Erlang.

Various actor languages did have selective receive, for example the
"communication handlers" of Act2 and Act3. In any case, selective
receive does not affect the expressive power of a message passing
model: it can be simulated, albeit inefficiently, by receiving
unconditionally and then re-sending the message to self if necessary.

CSP uses synchronous message passing; actors and Erlang are asynchronous.
For a comparison of actors with CSP, see <>.

> Also, it appears as if
> computation paths triggered by messages are concurrent,
> which would imply spawning another process for each message
> (or simply ignoring this, and serializing everything within
> the actor/process.)

You say "spawning another process" as if it's expensive or difficult.
The pure actor model uses continuation passing style, and compilation
of sequential code into this model does involve creating an actor for
every continuation. That doesn't mean that you would write code in a
high-level actor language in continuation passing style.

The reason that *kernel* actor languages take concurrent behaviours as
primitive is that concurrent behaviours and message passing are sufficient
to express sequential control flow (see /Viewing Control Structures as
Patterns of Passing Messages/), whereas sequential behaviours would not
be sufficient to express concurrency. All high-level actor languages
provide both.

> To me, it sounds like you would need a control layer in order
> to do actor programming in Erlang. Perhaps you'd also then
> want to use explicit channels? Essentially, you'd write a
> framework for actor programming.

No, Erlang would directly be an actor language, but for the issues I
pointed out earlier in the thread.

David Hopwood <>

More information about the erlang-questions mailing list