Using locks_leader for distributed gproc - beta testing

uwiger · July 31, 2026, 7:57am

gproc has been around for a while, so I’m assuming it needs no introduction. I’m also assuming that most are mainly using the local gproc functionality.

Distributed gproc (global - ‘g’ - scope) has been dependent on gen_leader, which among other things expects a fixed set of candidate nodes. I have long had a background project creating a leader election behavior based on the locks algorithm, but as I’ve been busy for the past decade on projects that don’t really use distributed Erlang, I haven’t had time to finish it.

The other day, I managed to bring locks_leader to a robust state, where it reliably handles split-brain scenarios, and I also managed to move gproc over to use locks_leader instead of gen_leader. It’s currently in a PR, as I would like to get some user feedback on it:

github.com/uwiger/gproc

Replace gen_leader with locks_leader for gproc_dist (#207)

master ← uw-new-locks_leader

opened 11:07AM - 30 Jul 26 UTC

uwiger

+767 -296

Port distributed registry to locks_leader: optional locks application, conditio…nal gproc_dist start when locks_server is present, and optional peer connect via {gproc, gproc_dist} node list. Testing: Common Test gproc_dist_SUITE with peer nodes and per-node disk logs; eunit keeps local coverage (dist eunit generator removed). Drop rebar.config.script that previously gated gen_leader.

The main advantage of this is that locks_leader adapts seamlessly to ad-hoc Erlang networking, so it will pick up new candidates as easily as e.g. global does.

As it needs no pre-configuration, I have also made gproc_dist start automatically, and no longer be gated by the GPROC_DIST environment variable. It will start automatically if the locks application is present, which it of course will be if rebar3 is used. If the locks application can’t be started, local gproc still works, but gproc_dist won’t be available.

I’m aware that many people use gproc already, so I prefer not to merge the PR until I get some solid feedback from existing users.

BR,
Ulf

Led · August 3, 2026, 6:05pm

Have you tried using ra instead of gen_leader?

uwiger · August 11, 2026, 7:08am

No, but when working on locks_leader, I had an eye towards implementing Raft on top of it.

The benefit of using locks_leader rather than Raft’s standard leader election might be that locks_leader doesn’t use backoff (except briefly in some extreme cases while healing from netsplits). So it elects leaders faster, and is more dynamic.

Something that the Raft protocol does that locks_leader didn’t was to ensure that leaders aren’t switched unnecessarily. In locks_leader, this is addressed by allowing the newly elected leader to surrender to another candidate.

gproc could likely use ra without much issue, but I haven’t looked into it yet. And since I’m not currently working on any products that need global gproc, I may not get around to it soon. Contributions are always welcome.