ARCHIV

Jak rozumně po fork() a v synovi exec() do rodičovského procesu protlačím informaci, zda exec() uspěl? Hlavně v případě, že ten exec() uspěl si nevím rady, jelikož v synovi již běží cizí kód. Pokud exec() neuspěje, tak to nějak přes meziprocesovou komunikaci protlačím. Motivace: dělám si takovou knihovničku (C++, unix a MS windows, http://www.linuxsoft.cz/sw_detail.php?id_item=832) a chci tam napsat funkci na spuštění programu. V MS windows je to jen převolání API funkce CreateProcess. Poradí mi někdo? Dík.

Tradicne se to resi tak, ze pokud exec(2) neuspeje, vrati se nejaka specialni hodnota pres exit(3), nelze pak poznat, jestli proces skoncil s tou hodnotou proto, ze selhel exec, nebo proto, ze ji vratil ten program (coz je typicky stejne jedno, protoze pokud to nekoho zajima, tak ho zajima, jestli ten proces vratil nulu).

Asi by se to dalo resit pres IPC s tim, ze pokud nic pres IPC neprijde, tak exec(2) probehl uspesne.

A nebylo by lepsi pouzit system(3) ci popen(3)? Neumi to sice uplne vse co CreateProcess, nicmene rekl bych, ze na ty nejcastejsi pripady je to vice nez dostacujici.

Tradicne se to resi tak, ze pokud exec(2) neuspeje, vrati se nejaka specialni hodnota pres exit(3), nelze pak poznat, jestli proces skoncil s tou hodnotou proto, ze selhel exec, nebo proto, ze ji vratil ten program (coz je typicky stejne jedno, protoze pokud to nekoho zajima, tak ho zajima, jestli ten proces vratil nulu).

Cekani s timeoutem na exec. (Zdrzovani.) Mozna kolize specialni hodnoty.

Asi by se to dalo resit pres IPC s tim, ze pokud nic pres IPC neprijde, tak exec(2) probehl uspesne.

Cekani s timeoutem na IPC. (Zdrzovani.)

system(3)

Nezadouci cekani na dokonceni prikazu. (Hrozne zdrzovani.)

popen(3)

Vynucené přepípování syna, vynucený shell.

Nakonec jsem to vymyslel. Pomohlo mi zavření pípy při execu. Tohle mi (aspoň na mém počítači) funguje výborně:

#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
int main(void) {
  int i;
  pid_t id;
  int pp[2];
  pipe(pp);
  id = fork();
  if (id) {
    char c;
    close(pp[1]);
    int precteno = read(pp[0], (void *)&c, 1);
    printf("Predek: exec syna se %spodaril\n", precteno ? "ne": "");
    close(pp[0]);
  }
  else {
     close(pp[0]);
     execlp("ls", "ls", "-l", NULL);
     write(pp[1], (void *)&i, 1);
     close(pp[1]);
  }
  return 0;
}

Tohle opravdu funguje i bez fcntl(pp[1], FD_SETFD, FD_CLOEXEC) ?

Díky za podnětnou otázku. V nějakém návodu, jsem četl, že to FD_CLOEXEC je třeba nastavit, ale u mně (stará Mandriva) to funguje i bez toho. Zřejmě je CLOEXEC (aspoň na mém počítači) u pípy nastaveno defaultně. Každopádně bude lepší to fcntl zavolat, kdo ví, jak by to bez toho fungovalo na jiných systémech.

No single unix specification rika, ze "The O_NONBLOCK and FD_CLOEXEC flags shall be clear on both file descriptors.". Coz mi prijde vcelku logicke.

A kdyz jsem to ted vyzkousel, tak jsem prisel na to, ze na mem pocitaci to sice na prvni pohled vypada, jako kdyby to fungovalo i bez CLOEXEC, ale nefunguje. Vypada to jako kdyby to fungovalo proto, ze se ta roura zavre ukoncenim toho procesu, coz v pripade toho ls nastane pomerne brzy.

Aha. Tak já si to pak schválně doma (v práci mám bohužel wokna) vyzkouším s něčím delším než ls. Ale každopádně to CLOEXEC ve výsledném kódu nastavím. Díky za rady a průzkum.