Process discovery in a large OTP system

Ulf Wiger ulf@REDACTED
Tue Sep 6 21:54:21 CEST 2005

Den 2005-09-06 15:27:52 skrev Tim Bates <tim@REDACTED>:

> I've also heard someone say on this mailing list that they seldom use  
> registered processes, which smacks of global state, and instead manage  
> to pass around pids to only the processes that need them. Again, I don't  
> know of an elegant structure that would allow me to do this for all the  
> disparate parts of my system.

I am moving in the opposite direction. A first attempt was
the proc_reg contrib in Jungerl. I've developed it further
(not released yet - sorry) and find the concept very

Basically, you allow processes to register using any term,
and if they want to, register under multiple names.
Furthermore, you allow them to publish 'properties'
which do not have to be unique. Think of processes as
actors (which they _are_), and the process registry as
the yellow pages, allowing you to find the right actor(s)

Add functions to easily operate on serveral actors at
the same time - folding over a property in the process
dictionary, for example. This can be used as a publish-
subscribe pattern:

subscribe(Event) ->
    procs:add_property({subscriber, Event}).

notify(Event) ->
    procs:fold_property(fun({_, Pid}, Acc) ->
                             Pid ! {event, Event}
                        end, ok, {subscriber, Event}).

This way, inspecting the published properties of an
event tells you stuff about that process, dependencies
towards different resources, group membership, etc,
and when using the shell for debugging etc, you can
rely on the process dictionary to efficiently select
subsets of all processess for inspection.

Ulf Wiger

More information about the erlang-questions mailing list