fork () pode falhar: isso Ă© importante

Eh, garfo (). Alguns processos dĂŁo origem a outros. Acho que tenho uma histĂłria sobre isso.



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 -1equivalente 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.



All Articles