fork/exec jeste jednou

[David Sauer]

>>>> "Petr" == Petr Novotny <Petr.Novotny na antek.cz> writes:

    >> setpgrp nastavuje nove "id skupiny procesu". Pokud totiz
    >> program(demon) neprovede nastaveni noveho id, lze ho ovlivnit
    >> signalem zaslanym prislusne skupine procesu odforkovanych od
    >> spolecneho predka (tedy od predka, ktery provedl setpgrp, jinak je
    >> spolecnym predkem proces init).

    Petr> Zatim v tom plavu: Predpokladejme kod ve tvaru

    Petr> pid_t pid=fork();
    Petr> if (pid==-1)
    Petr> { // a sakra!
    Petr> }
    Petr> else if (pid==0)
    Petr> {
    Petr>   setpgrp();
    Petr>   exec("nejaky proces",...);
    Petr> }
    Petr> else
    Petr> {
    Petr>   return;
    Petr> }

    Petr> Predpokladejme, ze return je nekam uplne pryc, a ze tento program ani
    Petr> jeho rodic nic nevedi o tom, ze mohl existovat nejaky "nejaky
    Petr> proces". Co se stane? Vyzombi se mi "nejaky proces" anebo ne?

No, mohl sis to zkusit. Ale samozrejmne ze se vyzombi, protoze parent
nedal najevo, ze nestoji o navratovy status potomka [to udela onim
volanim signal(SIGCLD, SIG_IGN)].
  Volani setpgrp s tim nesouvisi, je to jen k tomu, aby odforkovany
 (a execnuty) proces [to je teda cestina :-)] nebylo mozno ovlivnit
 jako clena skupiny procesu od jednoho predka(v tomto pripade je
spolecnym predkem init). Priklad:

       	       	       	   init
			    | (fork)
                           init1 (vola setpgrp)
                            | (exec)
                           demon

V takovem minisystemu budou dve procesove skupiny: skupina 1 s
procesem init (id skupiny procesu = pid procesu init) a skupina 2 s
procesem demon (id skupiny procesu = pid procesu init1, po execu
demon). Pokud by proces demon odforkoval proces demon1, a nebylo
 pritom provedeno setpgrp, proces demon1 by take patril do skupiny
 procesu demon.

--
* David Sauer, student of Czech Technical University
* electronic mail: davids na iol.cz (mime compatible)