[erlang-questions] Gproc synchronization primitives?

[Gregory Haskins]

On Apr 19, 2011, at 5:52 PM, Ulf Wiger wrote:

> 
> Hi Greg,
> 
> I've been thinking about adding such a function, so…
> 
> Try the new version I just pushed (v0.2.3), and see if it helps.
> 

Cool, thanks for your super responsiveness on all this!

> gproc_dist:sync() is the function to call.

I updated and added the code, but I ran into a potentially unrelated snag before I could verify if this fixed the issue.  That is:

(agent@REDACTED)23> Pid.
<0.73.0>
(agent@REDACTED)24> qlc:e(qlc:q([{P, K, V} || {{p, g, {edist_fact, K}}, P, V} <- gproc:table(props), K =:= "hostname"])).
[{<0.73.0>,"hostname","linux-mp"}]
(agent@REDACTED)25> qlc:e(qlc:q([{P, K, V} || {{p, g, {edist_fact, K}}, P, V} <- gproc:table(props), P =:= Pid])).       
[]

I would have expected the last run to return quite a few matches, but I got 0.  I haven't traced the gproc code yet to see if I can figure out what is happening, but it appears as though my guard expression against the PID is not working.  Do you spy anything I am doing wrong in the QLC, or would you expect this to work?

(As an aside, I may have mis-diagnosed the sync() problem since I _thought_ the empty set was being returned because of (lack of) sync.  In retrospect, it was probably this guard problem instead. That said, I think the sync() feature is a good one in general, so im glad it was implemented.

Thanks again for all the help and fast turn around on the code/questions.  Appreciated!

-Greg

> 
> As a general comment, at least gen_leader ensures that replication happens before the reply is delivered to a leader_call(). This is so that the caller should not be surprised by the newly written data not being there when the call returns.
> 
> BR,
> Ulf W
> 
> On 19 Apr 2011, at 23:18, Gregory Haskins wrote:
> 
>> Does any mechanism exist to synchronize with the distribution protocol
>> in gproc?  Heres what I am running into at the moment:
>> 
>> I have an FSM which runs out at an arbitrary end-point that registers a
>> bunch of {p, g, } properties:
>> 
>> https://github.com/ghaskins/edist/blob/6f2ab65114c9f92586d3fed17e463eec5742a070/agent/app/src/main/erlang/session_fsm.erl#L23
>> 
>> Later, that FSM might receive an async event that the "controller"
>> service is now available which compels the FSM process to communicate
>> with that remote process:
>> 
>> https://github.com/ghaskins/edist/blob/6f2ab65114c9f92586d3fed17e463eec5742a070/agent/app/src/main/erlang/session_fsm.erl#L30
>> 
>> The problem with my current design is the controller_api:join() RPC is
>> expecting to have visibility to the properties registered in the gproc
>> namespace.  Given that the FSM in question and the gproc distribution
>> mechanism are independent entities, I have thus introduced a race
>> condition (and one that almost always loses, I am finding).
>> 
>> Here are some possible ways to fix it:
>> 
>> 1) some kind of gproc:sync() primitive, or even gproc:sync(Node).  Not
>> sure if this already exists, could be easily invented if not, or would
>> be frowned upon?
>> 
>> 2) use gproc:await() (and friends) to discover the controller, with the
>> premise being that "if I can see you, you can presumably see me".  Not
>> sure if this assumption is true?
>> 
>> 3) Stop trying to use gproc in a timing sensitive way? (FWIW: I used to
>> pass the property-list as a parameter in the RPC before I switched over
>> the gproc, which of course did not have the race issue).
>> 
>> Any other suggestions?
>> 
>> Kind Regards,
>> -Greg
>> 
> 
> Ulf Wiger, CTO, Erlang Solutions, Ltd.
> http://erlang-solutions.com
> 
> 
>