[erlang-questions] Accessing sibling processes in a supervisor.

Karolis Petrauskas <>
Thu Jan 3 18:49:23 CET 2013


    I ended up by using gproc as a process registry instead of
maintaining sibling pids manually. That simplified my application
notably. I found it very convenient to use gproc with the standard
behaviours using the process name in form of {via,gproc,{n, l,
{?MODULE, Key}}}, where Key is known for all the related processes. In
my case the related processes receive the Key from the supervisor as a
initialization argument.

Thank you all for the comments,

On Fri, Dec 21, 2012 at 3:49 AM, ノートン ジョーセフ ウェイ ン
<> wrote:
> Karolis -
> I'd recommend to study gproc (https://github.com/uwiger/gproc) and in particular it's process registry features.  Worker processes and/or other processes can query the set of active processes using gproc:first/1, gproc:next/2, gproc:select/{1,2}, etc.
> For example, a worker process could register themselves with a key such as {?MODULE, self()}.  If worker processes have a unique identifier, a worker process could register themselves with a key such as {?MODULE, Id::term()} where term() is an unique identifier.
> Hope this helps.
> Joe N.
> On Dec 21, 2012, at 10:24 , Karolis Petrauskas <> wrote:
>> Hi,
>> I have a question regarding an example [1] in LYSE. The example
>> proposes a supervision scheme for a server-worker like processes. I
>> have used this scheme a lot (I learnt Erlang from this book mainly),
>> but now I'm in doubt. Is the proposed way of accessing a sibling
>> process (access worker_sup from ppool_serv, see [1]) is the correct
>> one? How will the ppool_serv get a PID of the worker_sup after a crash
>> and restart? As I understand, if one of the processes will crash, both
>> processes will be restarted and the server should get an error while
>> starting the worker_sup again (the corresponding child already
>> exists):
>>    handle_info({start_worker_supervisor, Sup, MFA}, S = #state{}) ->
>>        {ok, Pid} = supervisor:start_child(Sup, ?SPEC(MFA)),        %
>> Will this work after restart?
>> Or maybe I missed the point? I am aware of some other ways of getting
>> processes to know each other [2], but I would like to get your
>> comments on this example. Other schemes for implementing communication
>> of anonymous sibling processes (in the supervision tree) would be
>> interesting also.
>> [1] http://learnyousomeerlang.com/building-applications-with-otp#implementing-the-supervisors
>> [2] http://erlang.2086793.n4.nabble.com/supervisor-children-s-pid-td3530959.html#a3531973
>> Best regards,
>> Karolis Petrauskas
>> _______________________________________________
>> erlang-questions mailing list
>> http://erlang.org/mailman/listinfo/erlang-questions

More information about the erlang-questions mailing list