[erlang-questions] ETS tables and pubsub

Ulf Wiger ulf@REDACTED
Wed Nov 13 21:03:03 CET 2013

On 13 Nov 2013, at 20:27, Christopher Meiklejohn <cmeiklejohn@REDACTED> wrote:

> 1. It’s reliance on gen_leader, and it’s problems with deadlocks, dynamic membership and network partitions.
> 2. gproc’s resolution strategies for conflicting values after resolution of a network partition.

This is partly why I prefer the locks_leader version.

The locks_leader actually *only* supports dynamic membership right now, but could evolve to support a more restrictive strategy. It also has some added facilities for addressing the other candidates from within the elected() callback, in order to merge inside a protected state. This is used in the gdict example, but not in gproc.

Gproc doesn’t use it, since its dictionary isn’t transaction-consistent anyway.
The deconflict method in gproc is selected at registration time. Currently, three methods
are supported: exit_all, smallest_pid and largest_pid. It would be easy to add more, as
long as they are well-defined and safe in a distributed setting. Global has one alternative
where a user-provided function is called with the conflicting entries, and one entry is 
expected to be picked.

I’ll gladly take suggestions here.


BTW, in locks_leader, I’m currently experimenting with additions for supporting the
RAFT consensus algorithm. First, I added leader surrender, which seems to work
well. I’ve also added an ‘info’ attribute in lock entries, which could be used to select
the ‘best’ leader candidate (which would be done in the elected() callback, possibly
leading to a surrender to that candidate.

Of course, one doesn’t have to use locks_leader for a RAFT implementation
(I’m aware of rafter), but it was a fun challenge to see if it could be done.

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.

More information about the erlang-questions mailing list