[erlang-questions] Thoughts about server abstraction and process management

[Richard Carlsson]

Robert Virding wrote:
> 2009/3/25 Ulf Wiger <ulf.wiger@REDACTED 
>     zambal wrote:
>      > So I was wondering if there ever have been any ideas
>      > about process management like how memory is managed in
>      > garbage collected languages?
>      > I don't know anything about the internals of garbage
>      > collectors, but I can imagine that something like
>      > reference counted Pids could work: as soon as the last
>      > reference to a Pid in an Erlang node is cleared by
>      > the garbage collector and there's still a process
>      > active with that Pid, it should be pretty safe to kill it.
> 
>     I can recall that the idea has been discussed in the past,
>     but for better or for worse, it's rather too late for that.
>     It would probably break existing code in gruesome ways.
> 
> One difficult problem to solve if you do something like this is handling 
> references to pids from other nodes. As they can more or less be freely 
> passed around amongst external nodes there is no possibility to keep 
> track of them, or to keep track of which processes may, or may not, be 
> referenced.

One approach to distributed garbage collection is to use a lease-based
system. The idea is that an object/process will only stay alive as long
as some client still holds a valid lease. Once the last lease expires,
the object can be garbage collected. Clients will have to renew their
leases on a regular basis if they want to keep using the object. What
the default time for a lease should be depends on the problem; anything
between 100 milliseconds and 100 days could be reasonable.

With processes, you could make this a direct negotiation between the
process and its clients, but then the process needs to be explicitly
written to handle the lease system. You could also have a distinguished
service that manages leases on processes, and which will simply kill off
processes when their leases expire, by sending them an exit signal.

     /Richard