No se puede generar un supervisor de erlang de la cáscara

Question

He implementado un gen_server y el supervisor: test_server y test_sup. Quiero probar ellos de la cáscara / CLI. He escrito sus funciones start_link tal manera que sus nombres están registrados localmente.

he descubierto que puedo generar el test_server desde la línea de comandos muy bien, pero un test_sup generado no me permite interactuar con el servidor en absoluto.

Por ejemplo, puede generar un test_server ejecutando:

1> spawn(test_server, start_link, []).
<0.39.0>
2> registered().
[...,test_server,...]

Me puede interactuar con el servidor, y todo parece estar bien.

Sin embargo, si trato de hacer lo mismo con test_sup, no hay nuevos nombres / PIDS se registran en mi "proceso de línea de comandos" (usando registered/0). Mi test_server parece que se ha generado, pero no pueden interactuar con él (ver el comentario de Lukas Larsson sobre SASL para ver por qué esto es cierto).

Me asumir codifiqué un error en mi supervisor, pero este método de empezar mi supervisor funciona perfectamente bien:

1> {ok, Pid}= test_sup:start_link([]).
{ok, <0.39.0>}
2> unlink(Pid).
true
3> registered().
[...,test_server,test_sup,...]

¿Por qué es que puedo generar un gen_server pero no un supervisor?

---

Actualizar

El código que estoy usando se puede encontrar en este post . Estoy usando echo_server y echo_sup, dos módulos muy sencillos.

Dado que el código, esto funciona:

spawn(echo_server, start_link, []).

Y esto no:

spawn(echo_sup, start_link, []).

Answer 1

Esta explicación fue dada por Bernard Duggan en el href="http://forum.trapexit.org/mailinglists/viewtopic.php?t=18373" rel="nofollow noreferrer"> Erlang preguntas :

procesos vinculados no lo hacen de forma automática morir cuando un proceso al que están unidos finalice con el código 'normal'. Es por eso [Echo_server] no sale cuando el desove termina el proceso. Entonces, ¿por qué el troquel supervisor? Los detalles internos de El módulo supervisor de son de hecho sí implementa como una gen_server, pero con process_flag (trap_exit, true) conjunto. El resultado de esto es que cuando el muere proceso padre, terminan () obtiene llamada (lo que no ocurre cuando trap_exit está desactivado) y el el supervisor se apaga. Que tiene sentido en el contexto de un supervisor, desde un supervisor se genera por su padre en un árbol de supervisión - si no lo hizo morir cada vez que su parada de los padres, cualquiera que sea la razón, tendría colgando "ramas" del árbol.

Answer 2

Siempre que tratar de entender estas cosas por lo general es muy útil para encender SASL.

aplicación:. Partida (SASL)

De esa manera que se espera que llegar a saber por qué el supervisor está terminando.