Should client processing be added to the supervisor tree?

Question

in Erlang I have a process manager tree containing one that accepts tcp / ip connections. For each incoming connection, I create a new process. Should this process be added to the supervisor tree or not?

Regards, Steve

Answer 1

Yes, you must add these processes to the supervisory hierarchy as you want them to be correctly / gracefully terminated when your application is stopped. (Otherwise, you will end up leaking connections that fail, because the infrastructure of the applications on which they depend is disconnected).

You can create a simple_one_for_one strategy manager, say yourapp_client_sup , which has a child specification {Id, {yourapp_client_connection, start_link_with_socket, []}, Restart, Shutdown, worker, temporary} . The temporary type is important here because usually there is no reload strategy for the connection handler - you cannot connect to the client to restart the connection. temporary here will cause the supervisor to report the exit of the connection handler, but otherwise ignore it.

The process that makes gen_tcp:accept will then create a connection handler process by executing supervisor:start_child(yourapp_client_sup, [Socket,Options,...]) , not yourapp_client_sup:start_link(Socket, Options, ...) . Make sure that the function youreapp_client_connection:start_link_with_socket starts the child through the gen_server or proc_lib ( supervisor module requirement) and that the function transfers control to the socket to the child using gen_tcp:controlling_process , otherwise the child won’t use the socket.

An alternative approach is to create a fictitious yourapp_client_sup process that yourapp_client_sup processes can refer to at startup. The yourapp_client_sup process will exist only to propagate EXIT messages from its parent to the connection handler processes. He will have to catch the existing one and ignore all EXIT messages other than his parent's messages. In general, I prefer to use the simple_one_for_one supervisor approach.

Answer 2

If you expect that there will be many of these processes, it might be a good idea to add a supervisor under your main manager to separate the responsibilities (and maybe use the simple_one_for_one parameter to make things easier, maybe even easier than your current case).

The fact is that if you need to control these processes, it is always nice to have a supervisor. If that doesn't matter, if they succeed or not, then you may not need it. But then again, I always claim that this is sloppy coding .; -)

The only thing I would not do is add them to an existing tree, unless it is very obvious where they came from, and there are quite a few of them.