bitwalker
Pub/sub events for registrations
Is it in any way possible to "subscribe" to a Swarm registered process? Similar to Gprocs gproc_monitor:subscribe.
I want a process to be notified when a name becomes registered / unregistered (crash or shutdown). I can do this by looking up the Swarm name and then using Process.monitor on the PID, and keeping track of pid <-> name relation until it crashes, but that's a lot extra (and fragile) work.
Are there any plans of adding such a feature?
It could certainly be added, though I'm a bit confused on the purpose. If two processes are intrinsically tied together, you should link them, and if they are not, using monitors is a far better practice than having another process be the intermediary for up/down events. That said, I can see how pub/sub for group members would be useful - but I'm less convinced that pub/sub for all names globally is a good idea - it seems likely to a.) generate a lot of messages, b.) lack enough granularity to be useful for much.
Perhaps if you clarified your specific use case, it will become more apparent where this feature would fit in to the big picture?
Thanks for the reply, I'll explain my use case (it's a bit more complicated but here's a watered down version).
I'm building an app which has user connect through web sockets. These are temporary processes. Once connected they can join groups in order to talk to other users within that group. I'd like to send a swarm publish for that particular group to all members whenever someone chats.
In the event that a user disconnects in any way (user process crashes, or they simply close the browser) the process managing the group needs to be notified. This can easily be done by monitoring. However once the process restores itself, or the user opens the browser again, they need to automatically rejoin that specific group (if it still exists). This is not possible through monitoring, as you can't monitor a non registered process AFAIK.
These groups are also temporary, and if all members disconnect the group will be removed, meaning that if someone connects after the group has been removed they should NOT join.
This would be solvable if the group process could monitor the names of the users that connect / disconnect, similar to gprocs monitoring system. The way I'm solving it now is by publishing a message manually whenever a user connects, and the group listens to those publishes. And when a user properly shuts down it publishes again saying they are disconnecting. This isn't really a clean solution though as it could be unreliable during crashes.
PS: To clarify it's more complicated than just this, so I really need the man-in-the-middle process to tie these users together. It cannot be solved solely with just Swarm groups.
This is not possible through monitoring, as you can't monitor a non registered process AFAIK.
You can definitely monitor any PID, not just registered ones, but perhaps I'm misunderstanding what you mean by what isn't possible.
You could also handle the joining/leaving by simply publishing a message when the user process starts/terminates. Swarm does monitor group memberships as well as names (in the same way basically, though obviously name registration is more complicated for other reasons), so there isn't a theoretical reason why I couldn't add an API to subscribe to such notifications, but I would only want such subscriptions to occur on the group level (which makes it much easier to generate the proper events, and prevents generating a bunch of events that just get ignored).
You can definitely monitor any PID, not just registered ones, but perhaps I'm misunderstanding what you mean by what isn't possible.
Sorry, I meant that you can't monitor a NAME while it isn't assigned to a pid. Meaning that if it becomes registered you won't be notified.
You could also handle the joining/leaving by simply publishing a message when the user process starts/terminates.
This is what I'm currently doing through the GenServer init / terminate callback. Though IIRC there are some cases that terminate doesn't get called but I could be mistaken.
I understand that you would only want to implement this on the group level because of the potential large amount of ignored messages. I'm honestly not sure how Gproc handles this issue. Doing this on the group level wouldn't really solve my issue though, so I think I'll have to stay with the start/terminate publishing.
Thanks for the replies, feel free to close this ticket.
PS: Love this library though :)
I'll keep this open for now while I think on it. I have some work on the internals I'm doing over the next few days or so, and depending on how that goes I may go ahead and introduce the feature. Thanks for the kind words :)