[erlang-questions] grpoc for session management

Pablo Platt pablo.platt@REDACTED
Wed Feb 10 01:24:04 CET 2010

I now understand better when to use gproc.

gproc monitors all the processes that have register name/property/counter.
Does it make sense to add a callback function and args that gproc will call when the process terminates unexpectedly?
Maybe it's just my use case but I have a feeling that usually when you register a process you'll also be interested to know when it dies.
gproc already monitors processes so maybe it makes sense.
It can be set with 'm' for monitor:
reg({m, l, my_callback}, [arg1, arg2])


From: Ulf Wiger <ulf.wiger@REDACTED>
To: Pablo Platt <pablo.platt@REDACTED>
Cc: erlang-questions@REDACTED
Sent: Tue, February 9, 2010 11:57:24 PM
Subject: Re: [erlang-questions] grpoc for session management

Pablo Platt wrote:
> In your article you compare the performance of gproc to ETS
> and find that gproc is three time slower when storing a property.
> What is the reason?

Gproc has to store the property, a reverse mapping,
and ensure that the gproc server has a monitor on
the process.

> What will be the performance and memory of gproc compared to storing properties in the process state?

Basically, the reverse mapping doubles the memory
consumption in the normal case.

> I realize that gproc let you query properties from outside the process but
> what would you use for storing the user online friends for example?
> Assuming this data will only be accessed from the process itself.

Seems like a dictionary of sorts in the process state would
be better for that sort of thing.

Gproc is mainly a way to "publish" properties about a process
that make it easier to find that process, individually or as
part of a group. It comes with some bookkeeping overhead, but
in most cases where that sort of functionality is useful, I
think its definitely fast enough for practical use.

Ulf W
-- Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd



Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.



More information about the erlang-questions mailing list