[erlang-questions] conditional pub-sub in gproc

[Ulf Wiger]

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