[erlang-questions] conditional pub-sub in gproc

[Loïc Hoguin]

That removes some functionality though, doesn't it. Like :get_value/1 
and where/1. How would you suggest using these without global gproc?

On 06/16/2012 12:31 AM, 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
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines