[erlang-questions] pg2 vs gproc?

[Mahesh Paolini-Subramanya]

http://www.youtube.com/watch?v=R8yLKEj1WhQ&feature=related

Seriously tho'.  If, and when you get around to it, some of us would be ridiculously grateful, and would happily by you as much beer as you could possibly drink. Or Negronis.  Whichever :-)

Mahesh Paolini-Subramanya
That Tall Bald Indian Guy...
Blog   |   Twitter   |   Google+

On Jun 6, 2012, at 9:33 AM, Ulf Wiger wrote:

> 
> Yes, this is correct.
> 
> Gproc supports a few different types of register entries:
> 
> - names, which are unique (can be any term)
> - properties, which can be held by multiple processes simultaneously
> - counters, which are properties with update_counter() semantics
> - aggregate counters, which maintain the sum of all counters with
>   the same name as the aggregate counter.
> 
> Properties are very useful for pub-sub, but also for highlighting various characteristics of the process. In my initial presentation of gproc, I had integrated it into OTP and modified the behaviors to register a {p,l,{behaviour,B}} property. This way, you could easily query the system for a certain type of behavior, and drill further to inspect other things.
> 
> (This had the unfortunate side-effect that many thought you had to have a patched OTP to use gproc. Next time, I will try to be smarter).
> 
> Thus, if you inspect a process, either with gproc:i(), or gproc:info(Pid [, gproc]), you can easily tell from its registered names and properties quite a bit about the process.
> 
> 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…. ;-)
> 
> BR,
> Ulf W
> 
> On 6 Jun 2012, at 14:50, Eric Moritz wrote:
> 
>> 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.
>> On Jun 6, 2012 8:27 AM, "Loïc Hoguin" <essen@REDACTED> wrote:
>> On 05/26/2012 10:38 PM, Motiejus Jakštys wrote:
>> 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).
>> 
>> Unless I misunderstand, gproc's properties are exactly this, mapping one key to several processes.
>> 
>> -- 
>> Loïc Hoguin
>> Erlang Cowboy
>> Nine Nines
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
> 
> 
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

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