[erlang-questions] pg2 vs gproc?
Motiejus Jakštys
For term() to pid() mapping I've always used gproc. For the same thing
my coworker always used pg2.
I am making a comparison now. There are some features in gproc which are
not in pg2:
* Await for registration
* Per-process properties
* Aggregate counters
* QLC
Whereas pg2 "natively" supports mapping one key to several processes
(which can be easily achieved with QLC in gproc).
Any more differences between them?
Thanks,
Motiejus
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Motiejus Jakštys
On Sat, May 26, 2012 at 10:38 PM, Motiejus Jakštys
<desir...@gmail.com> wrote:
> Hi,
>
> For term() to pid() mapping I've always used gproc. For the same thing
> my coworker always used pg2.
>
> I am making a comparison now. There are some features in gproc which are
> not in pg2:
>
> * Await for registration
> * Per-process properties
> * Aggregate counters
> * QLC
>
> Whereas pg2 "natively" supports mapping one key to several processes
> (which can be easily achieved with QLC in gproc).
>
> Any more differences between them?
--
Motiejus Jakštys
Loïc Hoguin
> Hi,
Hello,
> For term() to pid() mapping I've always used gproc. For the same thing
> my coworker always used pg2.
>
> I am making a comparison now. There are some features in gproc which are
> not in pg2:
>
> * Await for registration
> * Per-process properties
> * Aggregate counters
> * QLC
>
> Whereas pg2 "natively" supports mapping one key to several processes
> (which can be easily achieved with QLC in gproc).
key to several processes.
--
Loïc Hoguin
Erlang Cowboy
Nine Nines
Eric Moritz
Yes, if you register a property key, you can retrieve all the procs that have that property set. For instance a fanout pub/sub can be accomplished doing:
subscribe(Channel) ->
gproc:reg({p, l, {subscribers,
Channel}}).
publish(Channel, Msg) ->
gproc:send({p, l, {subscribers,
Channel}},
Msg).
If a process calls publish/2, the message will be sent to every process that called subscribe/1.
I'm on my phone so it's a bit hard to look up the details, if you want to get a list of pids that called subscribe, look at the code of gproc:send/2. I think the function is called lookup_pids/1 but I may be wrong.
The etorrent project uses gproc. That's a good read if you want to see how to use gproc. He uses property keys for each torrent file process as well as using await to delay initialization of gen_servers that depend on other gen_servers.
Eric Moritz.
Ulf Wiger
Loïc Hoguin
> BTW, I've been thinking about adding a function, gproc:bcast(Key, Msg),
> which would be similar to:
>
> rpc:abcast(gproc, send, [Key, Msg])
>
> but with more predictable sequencing behavior, most likely making use of
> a gproc_bcast server to make sure all messages go the same way.
>
> Wild cheers and enthusiasm may intice me to do it sooner rather than
> later…. ;-)
Mahesh Paolini-Subramanya
Michael Truog
fun intellectual exercise.
On 06/06/2012 05:10 AM, Motiejus Jakštys wrote:
> Bump
>
> On Sat, May 26, 2012 at 10:38 PM, Motiejus Jakštys
> <desir...@gmail.com> wrote:
>> Hi,
>>
>> For term() to pid() mapping I've always used gproc. For the same thing
>> my coworker always used pg2.
>>
>> I am making a comparison now. There are some features in gproc which are
>> not in pg2:
>>
>> * Await for registration
>> * Per-process properties
>> * Aggregate counters
>> * QLC
>>
>> Whereas pg2 "natively" supports mapping one key to several processes
>> (which can be easily achieved with QLC in gproc).
>>
>> Any more differences between them?
Ulf Wiger
This is true. I prefer to recommend people to use gproc as a mainly local registry. Of course, just as with the built-in registry, using it doesn't limit your system to running on one node. It's just that the registry is local to each node. ;-)
The newest versions of gen_leader are supposedly more tolerant to netsplits, but no facility to merge the user-level data exists (esp. not in gproc). In this regard, mnesia is much better off, since there are ways to deal with netsplits and recover to a consistent state (even though those ways may not appeal to everyone).
Of course, as long as this issue remains, one should at least think twice before relying on global registration in gproc. It can still work, as long as there are system-level recovery measures after netsplits that also fix gproc (e.g. the system detects the problem, identifies a consistent island, and restarts all other nodes).
BR,
Ulf W
On 6 Jun 2012, at 18:44, Michael Truog wrote:
> The other differences are mentioned in previous email threads. pg2 replicates all name lookup information in a way that doesn't require consistency (it does use ets though, if you don't want to use ets, there is an example herehttps://raw.github.com/okeuday/CloudI/master/src/lib/cloudi/src/list_pg.erl). gproc uses gen_leader so it maintains a central name lookup authority. So, pg2 is AP from the CAP theorem, while gproc is CA. That means gproc has issues with partition tolerance, similar to mnesia. To me, gproc is a method by which you are able to introduce global variables into your Erlang program. This helps beginners that are not working on large codebases, but it is generally only for Erlang that is limited to a single node. An implementation of gen_leader behavior that is suppose to have better partition tolerance is here https://github.com/ngmoco/gl_async_bully , but I don't know the details. I don't see leader election as necessary in Erlang, though it is a
> fun intellectual exercise.
Ulf Wiger
OvermindDL1
>
> How to refuse such an offer? :)
>
> Well, a first version can be tested now.
>
> https://github.com/esl/gproc/blob/master/doc/gproc.md#bcast-2
Awesome, cannot wait to try it out. :)