Meyer, OO and concurrency

[David Hopwood]

Vance Shipley wrote:
> On Thu, Jul 14, 2005 at 11:03:03PM +0200, Ulf Wiger wrote:
> }  
> }  In Erlang, a process waiting indefinitely for something that
> }  will never occur is probably (but not certainly) in a faulty
> }  state. 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.
> 
> One can easily imagine an error handler which is simply never
> called into duty.  Distinguishing that from a process which 
> can't ever receive what it is waiting for would be impossible 
> if you're allowed dynamic code loading.

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.

The point of the definition of GC in actor systems is that it allows
you to use actors/processes as objects, in much the same way as you
would do in a conventional OO language, but in a message passing
concurrency model. In fact, an actor can represent any point on a
continuum of passivity -- reactivity -- autonomy, from completely
passive, stateless values, to thread-like processes that run continuously
and that communicate and cause effects autonomously. The conceptual
coherence of actor systems lies to a great extent in removing *artificial*
distinctions between these kinds of object.

Dynamic code loading makes essentially no difference to the design of
GC (any more than it does for conventional OO languages with dynamic
code loading, such as Java).

-- 
David Hopwood <david.nospam.hopwood@REDACTED>