Supervisor criança vs planície spawn_link

Question

Eu tenho uma hierarquia de processos chamada "monitor_node". Cada um desses monitor_nodes é supervisionado por um supervisor.

Agora, cada um desses nós pode ter uma estrutura interna complexa. Significado, pode (ou não) ter alguns subprocessos que são necessários para operar adequadamente. Exemplo: processo de envio de mensagens mantidas. Até agora eu tenho usado o spawn_link simples para criar esses "internos" processos.

No entanto, percebi que a desová-las na função Init do Monitor_node (que está sendo supervisionada) às vezes faz com que esta função falhe (e, portanto, toda a árvore de supervisor falhe). Minha pergunta é: seria uma boa solução para conectar esses processos internos à árvore de supervisor? Estou pensando em mudar o monitor_node para um supervisor que supervisiona seus processos internos.

minhas dúvidas são:

.

1. Eu teria que supervisionar um número bastante significativo de processos muito pequenos. Não tenho certeza se esta é uma boa prática.

2. Eu posso não saber com antecedência que o processo "interno" é um processo simples ou tem alguma estrutura interna (também desova outros processos). Se o último é o caso, então eu provavelmente deveria anexar esses processos "internos" à árvore de supervisor.

   Espero não ter confuso muito você. Ansioso por uma resposta.

   editar:

   um problema muito semelhante (se não o mesmo) é discutir aqui (3º poste). A solução dada é praticamente a mesma que a que dou as respostas de crap de deu.

Answer 1

Supervisors:

There is a trick here, which includes the use of two supervisors. Your tree goes like:

main_sup -> worker
main_sup -> attached_pool_sup

attached_pool_sup -> workers

main sup is one_for_all, so if the worker or the pool supervisor dies, then the tree is done for and killed off. The pool supervisor is a simple_one_for_one which are suitable for having hundreds or thousands of workers.

Init:

Don't do too much work in your init callback. The supervisor will wait until the init completes and you can set a timeout (which you can increase in your case) if it takes longer than normal.

A trick is to quickly timeout (return with a timeout of 0 from init) and then handle additional setup in the handle_info timeout callback. That way you won't be stopping up the main supervisor. Beware of races here!