[erlang-questions] Restarting processes

[Ulf Wiger (TN/EAB)]

I made an extended process registry a while ago,
called proc:

http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/proc/

Here's the edoc manual:
http://jungerl.cvs.sourceforge.net/*checkout*/jungerl/jungerl/lib/proc/d
oc/proc.html?revision=1.1

It allows processes to register under several different 
names, and the names don't have to be atoms. It also 
allows processes to register "properties", which do 
not have to be unique.


Properties can be used for a very simple publish-
subscribe pattern that would work in your case.

The subscriber publishes a property, and the publisher 
folds over a given property and e.g. sends a message to 
each process.

Example: 

demux.erl

subscribe() ->
   proc:add_property(property()).

notify(Event) ->
    proc:fold_properties(
        fun({_Prop, Pid}, _Acc) ->
            Pid ! {self(), ?MODULE, Event}
        end, [], property()).

property() -> {?MODULE, subscriber}.

As the subscriber property is registered with the 
subscriber process, and not kept by the publisher,
it remains even if the publisher is restarted.

An added bonus with the pattern is that properties 
become sort of a public registry of characteristics
and dependencies of properties - a process index,
which can be extremely helpful during debugging.

We've been using this solution in our products for
a while, and it has led to a radical simplification
of the code. It turned out that this was a pervasive
pattern in our applications, e.g. releasing all 
calls associated with a given signaling channel; 
identifying all processes involved in a given 
call setup; etc.

BR,
Ulf W


> -----Original Message-----
> From: erlang-questions-bounces@REDACTED 
> [mailto:erlang-questions-bounces@REDACTED] On Behalf Of 
> Daniel Ginsburg
> Sent: den 29 mars 2007 11:42
> To: erlang-questions@REDACTED
> Subject: [erlang-questions] Restarting processes
> 
> In my application I have a demultiplexing process and few 
> worker processes. The workers subscribe to events, the 
> demultiplexor gets requests from the network, and distributes 
> them to the workers, which handle them as appropiate.
> 
> The demultiplexor monitors (erlang:monitor) the workers, so 
> when a worker terminates without unsubscribing, the 
> demultiplexor cleans the subscription data.
> 
> Now, what if the demultiplexor itself die? Ok, 
> demultiplexor's supervisor will restart it. But what about 
> the workers? I don't want to terminate and restart them, 
> because workers carry quite a few state and I don't want that 
> state to be lost. So, I need my workers to resubscribe to 
> restarted demux. How can I handle it nicely?
> 
> I can have workers to monitor the demux. It solves a part of the
> problem: the workers would be notified if old demux die and 
> try to resubscribe to new demux getting it's pid via 
> whereis(demux_registered_name). But what if a worker get 
> {'DOWN', ...} message and tries to resubscribe, but the demux 
> isn't restarted yet or haven't finished the init stage? 
> Cleary a race contidition. I can introduce a small delay 
> after the {'DOWN, ...} message and attempted resubscription, 
> but this approach seems to be a bit ugly.
> 
> What I want to do is to have a some way for demux to announce 
> "Hey, I've just restarted and forgot all my subscribers. Now 
> I'm operational again.
> Whoever interested may resubscribe". Supervisors seem to be a 
> natural choice to relay that king of messages, since they are 
> always there. But it appears that OTP supervisors cannot do 
> that. How do you handle this kind of problems in your applications?
> 
> --
> dg
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>