<div dir="ltr">Awesome Fred!!!<div><br></div><div>I was precisely right now thinking about that grouping usage, since application_controller.erl has code like</div><div><br></div><div>    ets:match(ac_tab, {{application_master, '$1'}, Master})</div><div><br></div><div>used by application.erl as in</div><div><br></div><div>    application_controller:get_pid_all_env(group_leader())</div><div><br></div><div>which is like grepping based on the group leader. I think I read about this trick somewhere, but has checked several of the resources I normally consult and have failed to find it. Perhaps it was that code comment you mentioned.</div><div><br></div><div>The strange thing for someone like me studying this is that this use case seems unrelated to I/O, it is like hijacking the idea of group leader for something entirely different, so your confirmation helps.</div><div><br></div><div>Indeed, application masters seem to be just delegating to their previous group leader since it seems all I/O messages get forwarded up as in</div><div><br></div><div>     receive</div><div>     IoReq when element(1, IoReq) =:= io_request -></div><div>        State#state.gleader ! IoReq,</div><div>        ...</div><div><br></div><div>Also, if some subtree of the application changed the group leader, that grouping trick wouldn't work. Since the trick is in place in such a core module, I guess the conclusion is that you are generally not supposed to do that unless you know very well what you are doing.</div><div><br></div><div>José Valim also explained to me the use case of shells a while back.</div><div><br></div><div>Thanks a lot Fred!!!</div><div><br></div></div>