Meyer, OO and concurrency

Ulf Wiger <>
Fri Jul 15 03:21:48 CEST 2005

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.
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. 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. 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.)

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. If so, messages can be
forced to traverse a controlled channel, and are accepted only
if they have the proper format and arrive through the proper
channels. This would also open up possibilities for reachability

True, all this could be subverted. This is the problem of
adding a layer to a langugage that only almost conforms
to the wanted semantics.


More information about the erlang-questions mailing list