O garfo pode falhar. Voce entende? Na verdade, vocĂȘ entende? Ă muito sĂ©rio. O garfo pode falhar. O mesmo que malloc. Nem sempre, mas quando isso acontece, vocĂȘ nĂŁo pode simplesmente pegar e ignorar. VocĂȘ deve fazer algo neste caso.
Parece que todos sabem que fork retorna 0 para o processo filho e algum nĂșmero positivo para o pai - o pid da criança. Ele emite este nĂșmero, que Ă© usado posteriormente.
Adivinhe o que acontece quando vocĂȘ nĂŁo verifica a resposta de erro? Sim, vocĂȘ tratarĂĄ "-1" (erro de fork) como um pid vĂĄlido.
Isto Ă© apenas o começo. A verdadeira dor começa mais tarde, quando Ă© hora de enviar o sinal. VocĂȘ pode querer fechar o processo filho.
VocĂȘ estĂĄ fazendo kill (pid, sinal). Por exemplo, kill (pid, 9).
O que acontece quando quando pid Ă© -1? Ă muito importante saber isso. Muito importante.
...
...
...
Aqui vou colocar uma pĂĄgina de ajuda kill (2) do seu Linux.
Se pid for -1, entĂŁo sig Ă© enviado para todos os processos para os quais o processo de chamada tem permissĂŁo para enviar sinais, exceto para o processo 1 (init) ...
Vejo? Matar Ă©
pid -1
equivalente a matar todos os outros processos. Se vocĂȘ for um root, tudo acabou. VocĂȘ e init sĂŁo deixados. Todo o resto se foi, se foi, se foi
VocĂȘ tem cĂłdigo que controla os processos? VocĂȘ jĂĄ encontrou uma mĂĄquina completamente morta, exceto para o console de texto getty / login (que o init reinicia, Ă© claro) e o gerenciador de processos? Provavelmente culpado por este oomkiller no nĂșcleo?
Talvez nĂŁo seja culpa dele. Ă melhor verificar se vocĂȘ nĂŁo executou kill (-1).
O Unix tem armadilhas e armadilhas de urso suficientes para todos os gostos.