Process group scopes about ractor

[leonqadirie]

Thanks for the answers and the welcome! Let's see how it goes ;)

Dug a bit deeper into Erlang's pg module and got a bit surprised with the disjointness of scopes.
My updated understanding is:

• a process group is always in exactly one scope, and
• there can be multiple process groups with the same name, but in different scopes, so
• I must think of (scope, process_group) as an identifying tuple.

Is that correct?

[slawlor]

Ya I find their docs lacking in some of the PG designs. But if we diverge here for a more logical solution I think that's fine too. I'm happy to be based on what they have but it doesn't have to be exactly Erlang's implementation.

You're summary sounds correct to my knowledge but I have not dug deeply through PG mainly for lack of time.

[leonqadirie]

My questions before I might give it a try:

1. Is there anything discouraging implementation at this moment?
2. Is my understanding correct?
   • Scopes are (possibly non-disjoint) sets of process groups.
   • If no scope is explicitly set, all process groups are part of the default scope.
   • To join a non-default scope, processes have to be joined with process groups in the explicit (non-default) scope.
   • Processes can join any number of process groups in any number of scopes.
3. As Rust doesn't support variadic functions: Does ractor have preferences regarding the interface, i.e.,
   • splitting the functions into, e.g., a join and a join_with_scope(increasing the number of functions), or
   • setting an explicit Default function parameter for the scope (increasing noise when only using default scope), or
   • using macros for variadic interfaces?
4. Is there a technical reason the pg module's comments for the monitor/demonitor function mention 'scope or groups' already?

Can't promise anything but am curious so far.

[slawlor]

Hello! And thanks for taking this on :) I'll try and answer your questions here

1. Nope, just a level of complexity I wasn't willing to undertake when writing the core lib :)
2. This all sounds correct to me
3. Yeah this has been a slightly painful one, but I would lean towards multiple API calls one with scope, one without.
4. I think this is just a stale comment from when I first attempted adding scopes and got too in-the-weeds before realizing it was more straightforward without scopes.

I'm also not 100% sure but I believe there will be over-the-wire cluster protocol changes to support scopes in the protobuf specs, so that's something to check as well.

Thanks for taking this on, and welcome to the project!

[leonqadirie]

Thanks for the clarification and agreed. Will try to follow their design first.