[erlang-questions] Gproc synchronization primitives?

[Gregory Haskins]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110419/2fa47533/attachment.bin>