[erlang-questions] conditional pub-sub in gproc

[Tim Watson]

Oops, looks like I forgot to cc the list - sorry about that. Thanks for the clarification Ulf. It sounds like local use is a safer bet for now.

BTW I noticed some stdlib/kernel modules in the patches folder. What are these for?

Cheers,
Tim

On 15 Jun 2012, at 23:31, Ulf Wiger wrote:

> 
> Personally, I don't use global gproc. The latest gen_leader versions have improved in partition tolerance, but gproc makes no attempt at deconflicting the registry after netsplits.
> 
> My recommendation, if you want to use global scope in gproc, is to rig your system so that you can identify a minority island after netsplits, and restart those nodes.
> 
> Otherwise, you can use gproc's local scope, perhaps also including the broadcast function.
> 
> BR,
> Ulf W
> 
> On 15 Jun 2012, at 15:17, Tim Watson wrote:
> 
>> This is pretty cool - I also noticed await/1 for the first time, which looks pretty useful for synchronizing distributed startup. Looking at the code, gproc_dist seems to be using gen_leader. Is this something you'd be comfortable using in production (I assume yes) - I only ask because I've seen numerous threads talking about various incarnations of it, and I wondered whether it's considered stable now? I'm also very interested to know what kind of consistency guarantees I have when using this in a distributed scenario.
>> 
>> Cheers,
>> Tim
>> 
>> On 15/06/2012 19:33, Ulf Wiger wrote:
>>> I threw in a function for doing pub/sub with simple filter conditions in gproc.
>>> 
>>> https://github.com/esl/gproc/blob/master/doc/gproc_ps.md#subscribe_cond-3
>>> 
>>> A simple example:
>>> 
>>> Eshell V5.9  (abort with ^G)
>>> 1>  application:start(gproc).
>>> ok
>>> 
>>> %% Subscribe to level changes for a gauge; only report if Level>  3
>>> 
>>> 2>  gproc_ps:subscribe_cond(l,gauge,ets:fun2ms(fun({level,N}) when N>  3 ->  true end)).
>>> true
>>> 
>>> 3>  gproc_ps:publish_cond(l,gauge,{level,1}).
>>> ok
>>> 4>  flush().
>>> ok		% no message delivered
>>> 
>>> 5>  gproc_ps:publish_cond(l,gauge,{level,4}).
>>> ok
>>> 6>  flush().
>>> Shell got {gproc_ps_event,gauge,{level,4}}
>>> ok
>>> 
>>> Essentially, gproc attaches a match_spec to the subscription entry, and this
>>> match_spec is evaluated when each event is published.
>>> 
>>> If ets:match_spec_run([Msg], ets:match_spec_compile(Condition)) == [true],
>>> the message is delivered; otherwise not.
>>> 
>>> The match specs are stored un-compiled, partly because you can't pass
>>> compiled match specs between nodes (gproc's global scope), and partly
>>> because you can't read them when compiled, and it's useful to be able to
>>> inspect properties:
>>> 
>>> 7>  gproc:info(self()).
>>> [{gproc,[{{p,l,{gproc_ps_event,gauge}},
>>>          [{{level,'$1'},[{'>','$1',3}],[true]}]}]},
>>> {current_function,{erl_eval,do_apply,6}},
>>> {initial_call,{erlang,apply,2}},
>>> {status,running},
>>> …
>>> 
>>> Feedback is welcome.
>>> 
>>> BR,
>>> Ulf W
>>> 
>>> 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
>> 
> 
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
> 
> 
>