Meyer, OO and concurrency

[David Hopwood]

Ulf Wiger wrote:
> Den 2005-07-14 18:23:42 skrev David Hopwood  
> <david.nospam.hopwood@REDACTED>:
> 
>> 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
<http://groups.google.co.uk/group/comp.lang.functional/browse_frm/thread/6ef4f6cf47c9e536/6c1bf1798fc7f578?hl=en#6c1bf1798fc7f578>.

> 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
>>     systems).
> 
> ... part of the reason why processes are always reachable.

That's why the two issues above would have to be addressed at the
same time.

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

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 <david.nospam.hopwood@REDACTED>