[erlang-questions] gproc and gen_event

[Ulf Wiger]

On 19 May 2012, at 01:38, Andrew Berman wrote:

> Ok, cool, thanks Garrett.  
> 
> Do you have any experience using gproc for pub/sub?

Gproc does do pub/sub fairly well, but if I may, the main purpose of 
gproc initially was to serve as a form of "property index" for processes.

It had dawned on me that complex signaling applications tended to
end up with a lot of code that basically provided different sorts of 
mappings to allow you to locate the right processes. Having so many
different mappings complicated debugging, and obscured many 
aspects of the architecture.

When we started using (the predecessor of) gproc in some Ericsson
projects, there was significant code reduction. The nice thing was that 
the developers picked it up themselves; there wasn't really any central
decision to go with it.

One of the things I like about gproc is that it allows you to publish the
'interaction features' of a process: registered aliases say much about 
what services a process can perform, and properties illustrate its 
dependencies on other processes. The registry can be queried with
select operations or QLC, or simply with gproc:i() from the shell.

In short, there are many fine ways of doing pub/sub, but if you use 
gproc consistently for this sort of thing, and similar things, it can help
clarify runtime aspects of your system, making it more transparent and
easier to debug.

This also explains why gproc relies on a central registry (which is a
challenge in the global case). The registry itself is much of the point.

Of course, for a distributed pub/sub, you don't really need to turn on 
the distributed parts of gproc. Running a local gproc instance on each
node, you can publish like so:

publish(Event, Data) ->
   rpc:eval_everywhere(
      gproc, send,
      [{p, l, {?MODULE, Event}}, {?MODULE, Event, Data}]).

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120519/a27a5bca/attachment.htm>