<div dir="ltr">I recently increased the share of my own dogfood in my daily programming diet, which among other things might mean that I'll become a bit more responsive to support requests - let's hope.<div><br></div><div>I thought I'd mention my latest PR to gproc:</div><div><a href="https://github.com/uwiger/gproc/pull/126">https://github.com/uwiger/gproc/pull/126</a><br></div><div><br></div><div>From the edoc:</div><div><div>@spec multicall(Module::atom(), Func::atom(), Args::list()) -></div><div>{[Result], [{node(), Error}]}</div><div><br></div><div>@doc Perform a multicall RPC on all live gproc nodes</div><div><br></div><div>This function works like {@link rpc:multicall/3}, except the calls are</div><div>routed via the gproc leader and its connected nodes - the same route as</div><div>for the data replication. This means that a multicall following a global</div><div>registration is guaranteed to follow the update on each gproc node.</div><div><br></div><div>The return value will be of the form {GoodResults, BadNodes}, where</div><div>BadNodes is a list of {Node, Error} for each node where the call</div><div>fails.</div><div>@end</div></div><div><br></div><div>This is not something I personally need right now, but meditating over the test suite, it occurred to me that it might be useful. Given that gproc replicates asynchronously, there is a distinct risk of race conditions if you register a global entry and then want to perform an operation on remote nodes, based on the newly registered information (given that updates go through the leader and lookups are served locally).</div><div><br></div><div>The gproc_dist:multicall(M, F, A) function *should* (as far as I can tell) ensure that the multicall will always be executed after the successful update of a preceding entry. Note that this assumes that the registration and multicall originate from the same process.</div><div><br></div><div>Given that gproc_dist:multicall/3 is routed via the gproc leader, it will practically always be slower than an rpc:multicall/4, but for the intended use case, this is of course intentional (since being too fast means that the rpc:multicall/4 might race past the preceding registation.)</div><div><br></div><div>Feedback is welcome, esp. while the PR is waiting to be merged.</div><div><br></div><div>BR,</div><div>Ulf W</div></div>