Meyer, OO and concurrency

David Hopwood <>
Fri Jul 15 01:03:24 CEST 2005

Ulf Wiger wrote:
> David Hopwood <> wrote:
>> By default, debugging should not cause objects/processes to remain
>> alive if they would not otherwise do so. The debugger should hold only
>> weak references, unless the user specifically asks for some objects/
>> processes to be strongly referenced. The fact that normal code cannot
>> obtain a list of all processes doesn't prevent a debugger from being
>> able to do so; conceptually, the debugger is part of the language
>> implementation.
> But in this case, hanging processes can be debugged (even though
> it's usually not easy to figure out what they're waiting for),
> even if you didn't expect them to hang, and didn't have the
> debugger active.

In actors-style OO, a "hanging" process is not an error; it is quite
expected to have dead actors that can no longer receive any messages --
just as common as it is to have dead objects in any other OO language.

Note that processes that are intended to be continuously active until
explicitly terminated will typically have timeouts on message reception,
so they will not be GC'd.

> I really see this as a non-problem.  Erlang processes _are_
> automatically GC'd when they terminate. If they haven't
> terminated, they remain in memory. One could imagine a
> specification stating that a process waiting indefinitely
> should be automatically removed, but I have never considered
> it a problem that Erlang doesn't do so.

It is not a problem if you don't attempt to do actors-style OO in
Erlang. But the context was exactly that:

Peter-Henry Mander wrote:
# I've found that modelling a OO system in Erlang recovers the original
# concept of objects as concurrent actors.

I pointed out that one of the important differences is in the semantics
of GC.

In the comp.lang.functional thread, the context was whether Erlang's
processes were equivalent in expressive power to SML references; they
are not for the same reason.

What is rather frustrating is that Erlang is *almost* an actor language,
but doesn't quite make the grade because of issues like this one. There
is a community of potential users (including the capability-based security
community) who would love to use Erlang as an actor language, but without
these changes, that just isn't going to work. It would be a bit like trying
to do OO in a non-GC'd language, or trying to use OS threads as if they
were lightweight processes.

> In Erlang, a process waiting indefinitely for something that
> will never occur is probably (but not certainly) in a faulty
> state.

Well, this is simply not true of actor systems. So it can only be true
of Erlang systems that are not designed like actor systems.

> It is very difficult to determine that a message can
> never be sent.  Another process may be at fault, and the problem
> may be fixed by changing and reloading a module in some other
> part of the system.

If an object is not reachable and is in an infinite wait, then it can
be collected completely independently of any other code, and regardless
of whether other code can be reloaded.

David Hopwood <>

More information about the erlang-questions mailing list