Meyer, OO and concurrency
Thu Jul 14 21:46:37 CEST 2005
Ulf Wiger wrote:
> Den 2005-07-14 18:23:42 skrev David Hopwood
>> Peter-Henry Mander wrote:
>> Hi Gurus,
>> Sorry but I've got to stick my oar in.
>> I've found that modelling a OO system in Erlang recovers the original
>> concept of objects as concurrent actors.
>> Almost, but:
>> - Erlang does not garbage-collect processes when they are waiting
>> unconditionally for a message that can never be sent.
> This was discussed recently in comp.lang.functional and
> some other newsgroups.
Yes, starting at
> I think what came out of the discussion
> was that a process never becomes unreachable in Erlang, and
> thus, there is no way to determine that a process is waiting
> in vain. Besides, I believe that it's quite beneficial for
> debugging that a hanging process isn't automatically removed
> before anyone has a chance to inspect it.
>> - Erlang Pids are forgeable, and it is possible to enumerate
>> the Pids of all processes (which was prohibited in actor
> ... part of the reason why processes are always reachable.
That's why the two issues above would have to be addressed at the
> Also a great feature during debugging.
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
Note that a debugger necessarily has to be able to handle cases where
a value being watched becomes inaccessible, so doing so for processes
as well as other values does not add much complexity to the debugger
or its user interface.
>> - processes in Erlang implementations, although they are more
>> lightweight than threads, are still a bit too heavyweight to be
>> used in the same way as objects.
> Agreed. This is one reason why mapping OOD to Erlang is not
> such a great idea. For different types of object, you need to
> choose different implementations in Erlang. Every type of
> object can't reasonably be mapped onto a process.
I believe that it is quite feasible to implement Erlang (and similar
asynchronous message passing languages) in such a way that every type
of object can be reasonably mapped onto a process. I'll post a pointer
to more details about that soon.
David Hopwood <>
More information about the erlang-questions