[erlang-questions] ETS tables and pubsub

[Garret Smith]

Ulf, I need to up the priority of replacing gen_leader with your
distributed locker.  I've certainly experienced some of the problems
Christopher is talking about with gen_leader.

Christopher, great blog posts!  I need to go read some more, my first
skimming wasn't enough...

-G


On Wed, Nov 13, 2013 at 12:03 PM, Ulf Wiger <ulf@REDACTED> wrote:

>
> 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.
>
> BR,
> Ulf
>
> 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.
> http://feuerlabs.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131113/8a26473b/attachment.htm>