[erlang-questions] gproc and gen_event

Garrett Smith g@REDACTED
Fri May 18 23:30:20 CEST 2012


On Thu, May 17, 2012 at 7:14 PM, Andrew Berman <rexxe98@REDACTED> wrote:
> Hello,
>
> I am trying to set up a pub-sub type situation where I have a function
> called which does some stuff and at the end broadcasts a message.  I would
> like for multiple handlers to be able to receive that message and do
> something with it.  I'm currently using gen_event, but have been reading
> about gproc as well.  Can anyone explain why they'd use one over the other
> for pub/sub?

gen_event is useful when you need to support "pluggable" functionality
and you can't tolerate the overhead of Erlang message passing.

gen_event runs all handlers in a single process. If one of those
subscribers misbehaves, it's unceremoniously removed.

To give you an idea:

Eshell V5.8.5  (abort with ^G)
1> error_logger:info_msg("say hello").

=INFO REPORT==== 18-May-2012::16:13:25 ===
say hellook
2> error_logger:info_msg([{"say", "goodbye"}]).
ok
3> error_logger:info_msg("anyone?").
ok

error_logger uses gen_event -- tty support is a handler. Bugs, as the
one above, result in silent changes to your program!

While you can use add_handler_sup to get notification of a handler
delete, I find the whole facility easy to get wrong and so I avoid it.

But it's not hard to create a publisher in yourself. e2 [1] has
something you can steal from, or just use:

https://github.com/gar1t/e2/blob/master/src/e2_publisher.erl

Here's a silly example of a "broker" that decorates published messages
with some tag:

https://github.com/gar1t/e2/blob/master/examples/pubsub/src/broker.erl

The advantage of pubsub using Erlang messages over gen_event is that
you can implement more natural supervision -- and you're not going to
get silent, mysterious breakage. The price is that you're sending
Erlang messages. If you can't afford that (e.g. perhaps high
throughput logging) gen_event is better.

Garrett

[1] http://e2project.org/



More information about the erlang-questions mailing list