Meyer, OO and concurrency

Ulf Wiger <>
Thu Jul 14 23:03:03 CEST 2005

Den 2005-07-14 21:46:37 skrev David Hopwood  

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

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.

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.


More information about the erlang-questions mailing list