Descrierea standard¶

(Din POSIX.1 ) Funcția vfork() are același efect ca și fork(2), cu excepția faptului că comportamentul este nedefinit dacă procesul creat de vfork() fie modifică alte date decât o variabilă de tip pid_t utilizată pentru a stoca valoarea de returnare de la vfork(), fie returnează din funcția în care a fost apelată vfork(), fie apelează orice altă funcție înainte de a apela cu succes _exit(2) sau una dintre funcțiile din familia exec(3).

Descrierea Linux¶

vfork(), la fel ca fork(2), creează un proces-copil al procesului apelant. Pentru detalii și valoarea de returnare și erori, consultați fork(2).

vfork() este un caz special de clone(2). Acesta este utilizat pentru a crea procese noi fără a copia tabelele de pagini ale procesului părinte. Aceasta poate fi utilă în aplicațiile sensibile la performanță în care se creează un proces-copil care apoi emite imediat un execve(2).

vfork() diferă de fork(2) prin faptul că firul apelant este suspendat până când firul copil termină (fie în mod normal, prin apelarea _exit(2), fie în mod anormal, după transmiterea unui semnal fatal), sau efectuează un apel la execve(2). Până în acel moment, copilul împarte toată memoria cu părintele său, inclusiv stiva. Copilul nu trebuie să se întoarcă din funcția curentă sau să apeleze exit(3) (care ar avea ca efect apelarea gestionarilor de ieșire stabiliți de procesul părinte și golirea tampoanelor stdio(3) ale părintelui), dar poate apela _exit(2).

Ca și în cazul fork(2), procesul-copil creat de vfork() moștenește copii ale diferitelor atribute ale procesului apelantului (de exemplu, descriptori de fișiere, dispoziții de semnal și directorul curent de lucru); apelul vfork() diferă doar în ceea ce privește tratarea spațiului de adrese virtuale, așa cum s-a descris mai sus.

Semnalele trimise părintelui sosesc după ce copilul eliberează memoria părintelui (de exemplu, după ce copilul termină sau apelează execve(2)).

Descrierea istorică (veche)¶

În Linux, fork(2) este implementat folosind pagini copy-on-write, astfel încât singura penalizare suferită de fork(2) este timpul și memoria necesare pentru a duplica tabelele de pagini ale părintelui și pentru a crea o structură de sarcini unică pentru copil. Cu toate acestea, în vremurile de demult, un fork(2) ar fi necesitat realizarea unei copii complete a spațiului de date al apelantului, adesea inutil, deoarece, de obicei, imediat după aceea se realizează un exec(3). Astfel, pentru o mai mare eficiență, BSD a introdus apelul de sistem vfork(), care nu copia complet spațiul de adrese al procesului părinte, ci împrumuta memoria și firul de control al părintelui până la un apel la execve(2) sau până la o ieșire. Procesul părinte a fost suspendat în timp ce copilul folosea resursele sale. Utilizarea vfork() era complicată: de exemplu, pentru a nu modifica datele din procesul părinte, era necesar să se cunoască variabilele care se aflau într-un registru.

Avertismente¶

Procesul-copil trebuie să aibă grijă să nu modifice memoria în moduri neintenționate, deoarece astfel de modificări vor fi văzute de procesul părinte odată ce copilul termină sau execută un alt program. În această privință, gestionarii de semnal pot fi deosebit de problematici: dacă un gestionar de semnal care este invocat în copilul lui vfork() modifică memoria, aceste modificări pot duce la o stare inconsecventă a procesului din perspectiva procesului părinte (de exemplu, modificările de memorie ar fi vizibile în procesul părinte, dar modificările stării descriptorilor de fișiere deschise nu ar fi vizibile).

Atunci când vfork() este apelat într-un proces cu mai multe fire de execuție, numai firul de execuție apelant este suspendat până când copilul termină sau execută un nou program. Aceasta înseamnă că copilul împarte un spațiu de adrese cu alt cod care rulează. Acest lucru poate fi periculos dacă un alt fir de execuție din procesul părinte își schimbă acreditările (utilizând setuid(2) sau similar), deoarece există acum două procese cu niveluri de privilegii diferite care rulează în același spațiu de adrese. Ca exemplu al pericolelor, să presupunem că un program cu mai multe fire de execuție care rulează ca root creează un copil folosind vfork(). După vfork(), un fir de execuție din procesul părinte scade procesul la un utilizator fără privilegii pentru a rula un cod de neîncredere (de exemplu, poate prin intermediul unui modul deschis cu dlopen(3)). În acest caz, sunt posibile atacuri în care procesul părinte utilizează mmap(2) pentru a pune în memorie codul care va fi executat de procesul copil privilegiat.

Note Linux¶

Gestionarii de bifurcare stabiliți utilizând pthread_atfork(3) nu sunt apelați atunci când un program multi-fir care utilizează biblioteca multi-fire NPTL apelează vfork(). În acest caz, gestionarii de bifurcări sunt apelați într-un program care utilizează biblioteca multi-fire LinuxThreads. Consultați pthreads(7) pentru o descriere a bibliotecilor de multi-fire Linux.

Un apel la vfork() este echivalent cu un apel la clone(2) cu flags specificat ca:

 CLONE_VM | CLONE_VFORK | SIGCHLD

Istoric¶

Apelul de sistem vfork() a apărut în 3.0BSD. În 4.4BSD a devenit sinonim cu fork(2), dar NetBSD l-a introdus din nou; a se vedea http://www.netbsd.org/Documentation/kernel/vfork.html Linux, a fost echivalent cu fork(2) până la Linux 2.2.0-pre6 aproximativ. De la Linux 2.2.0-pre9 (pe i386, ceva mai târziu pe alte arhitecturi) este un apel de sistem independent. Suportul pentru acesta a fost adăugat în glibc 2.0.112.