How to find Pids of the children of a supervisor
Locked
How to find Pids of the children of a supervisor
 
|
I was asked the following in a direct mail to me:
"Given two worker processes in a supervision tree, A and B, if A wants to message B, how should it obtain the pid of B ?" Pretty good question. I think the answer is to use supervisor:which_children/1 and to name the supervisor and all the children. Is the the best way? - does anybody have an example? Cheers /Joe _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: How to find Pids of the children of a supervisor
|
|
On Thu, Dec 7, 2017 at 6:03 PM, Joe Armstrong <[hidden email]> wrote:
> I was asked the following in a direct mail to me: > > "Given two worker processes in a supervision tree, A and B, if A wants > to message B, how should it obtain the pid of B ?" > > Pretty good question. > > I think the answer is to use supervisor:which_children/1 and to name > the supervisor and all the children. > > Is the the best way? - does anybody have an example? Sure, I don't bother to name the supervisor though, pass the pid() down: Here's an example of a gen_server which locates it's sibling simple_one_for_one supervisors after initializing: https://github.com/sigscale/ocs/blob/8aafd48fd876b7434517b512d79d2c12559889bb/src/ocs_radius_auth_port_server.erl#L157 -- -Vance _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: How to find Pids of the children of a supervisor
|
|
> supervisor:which_children/1 > Is the the best way? - does anybody have an example? That and using erlang:process_info(Pid, links) are the only ways. The supervisor module lacks a child(SupRef, Name) function that would now be able to fetch children by Name with a complexity better than O(n) now that the module can use maps. I started writing a PR for that but then got confused by the code that can either use sets or maps: I couldn't understand which backend would be used when... My use case is to not register names for child processes (using erlang:register via {local,Name}). Cheers, -- Pierre Fenoll On 7 December 2017 at 14:26, Vance Shipley <[hidden email]> wrote: On Thu, Dec 7, 2017 at 6:03 PM, Joe Armstrong <[hidden email]> wrote: _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: How to find Pids of the children of a supervisor
|
|
I tend to use one out of the following solutions: * If the processes are truly "singletons" then I tend to register them in the registry (locally or globally) and then look them up there by name.On Thu, Dec 7, 2017 at 3:34 PM Pierre Fenoll <[hidden email]> wrote:
_______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
Re: How to find Pids of the children of a supervisor
|
|
On Thu, Dec 7, 2017 at 9:17 PM, Jesper Louis Andersen
<[hidden email]> wrote: > * Some of my old code used `supervisor:which_children()` but the more > experience I have, the more often I tend to use a registry application for > these kinds of things. Keeping a manager process, or an ETS table (gproc) is > usually an easier way to obtain other pids(). I like to stick to functional programming as much as possible, if a function needs some data pass it in as an argument. -- -Vance _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
|
|
In reply to this post by Joe Armstrong-2
On 2017年12月07日 木曜日 13:33:36 Joe Armstrong wrote:
> I was asked the following in a direct mail to me: > > "Given two worker processes in a supervision tree, A and B, if A wants > to message B, how should it obtain the pid of B ?" > > Pretty good question. > > I think the answer is to use supervisor:which_children/1 and to name > the supervisor and all the children. > > Is the the best way? - does anybody have an example? I tend to use a (semi) standard template of: service_sup service_manager worker_sup workers I wrote about it in a (poorly structured and unrevised) post here: https://zxq9.com/archives/1311 I'm going to take a stab at this frequently asked question here in email first, and maybe refine it into something worthy of a post on this specific subject later. The worker_sup may or may not even be started, things might be linked/monitored together in arbitrary ways, etc, but the basic pattern seems to always wind up forming one way or another regardless how the project is designed to start with (before assumptions have been subjected to reality). SOMETHING must be a named, universal interface to the service (from the perspective of other services in the system, assuming there is more than one), and very often the nature of the service itself is one where workers form arbitrary relationships amongst themselves. In the case of a broadcast-type service amongst processes (a chat service or update notification system, for example) the connection handlers are one service and the channels themselves are components of another: no peer lookup is necessary except when it comes time to find the pid of a channel to send a subscription request to -- then you send the lookup request to the named service manager of the chat service. In the case that the same chat or channelized service also supports private messaging, it would be natural for the connection handler's service manager to keep a registry of connected and active pids (which you would do anyway if you want to be able to inspect the system's active state in more interesting ways than merely looking up a list of child pids from the supervisor). So how to resolve a chat username to a pid? Any chat_client worker asks the chat_client_man -- and finds out maybe not just the pid, but also how long he's been logged on, whether he's logged on, IP, or whatever other `finger` type data might be tracked by the system. The bottom line is that this little pyramid of processes seems to nearly always be needed to define a discrete service, and every time you need to find a sibling's pid the reason for finding it dictates that you have some custom tracking and query code surrounding the lookup -- and that means the natural place for a lookup is in the service manager in nearly every case. -Craig _______________________________________________ erlang-questions mailing list [hidden email] http://erlang.org/mailman/listinfo/erlang-questions |
«
Return to Erlang Questions
|
1 view|%1 views
| Free forum by Nabble | Edit this page |