Last Change: 2018-09-07, 16:50
powered by manpag.es
vfork − crea un processo figlio e blocca il padre
#include <sys/types.h>
#include <unistd.h>
pid_t vfork(void);
Test delle funzioni e requisiti delle macro per glibc (vedere feature_test_macros(7)):
vfork(): _BSD_SOURCE || _XOPEN_SOURCE >= 500
Descrizione standard
(Dalla bozza SUSv2 / POSIX.) La funzione vfork() ha lo stesso effetto di fork(2), con l’eccezione che il comportamento è indefinito se il processo creato da vfork() modifica un dato qualsiasi che non sia una variabile di tipo pid_t usata per archiviare il valore restituito da vfork(), o torna dalla funzione nella quale vfork() è stato chiamato, o chiama qualunque altra funzione prima di chiamare con successo _exit(2) o una delle funzioni della famiglia di exec(3).
Descrizione Linux
vfork(), proprio come fork(2), crea un processo figlio del processo chiamante. Per dettagli sui valori restituiti e sugli errori, vedere fork(2).
vfork() è un caso speciale di clone(2). Si usa per creare nuovi processi senza copiare le tabelle di pagina del processo padre. Può essere utile in applicazioni sensibili alle prestazioni, nelle quali verrà creato un figlio che emette immediatamente un execve(2).
vfork() è diverso da fork(2) nel senso che il padre viene sospeso finché il figlio esegue una chiamata a execve(2) o _exit(2). Il figlio condivide la memoria con il padre, incluso lo stack, finché emette execve(2). Il figlio non deve tornare dalla funzione attuale o chiamare exit(3), ma può chiamare _exit(2).
I gestori del segnale vengono ereditati, ma non condivisi. I segnali al padre arrivano dopo che il figlio ha rilasciato la memoria del padre.
Descrizione storica
Sotto Linux, fork(2) è implementato usando pagine di tipo copy-on-write, così che la sola penalizzazione in cui incorre fork(2) è il tempo e la memoria richiesti per duplicare le tabelle delle pagine del padre, e per creare un’unica struttura di task per il figlio. Tuttavia, anticamente fork(2) richiedeva una copia completa dello spazio dati del chiamante, spesso senza che ce ne fosse bisogno, di solito immediatamente dopo l’esecuzione di exec(3). Quindi, per una maggiore efficienza, BSD ha introdotto la chiamata di sistema vfork(), che non copiava completamente lo spazio di indirizzamento del processo padre, ma prendeva la memoria del padre e il thread di controllo fino a una chiamata a execve(2) o un exit. Il processo padre era sospeso mentre il figlio utilizzava le sue risorse. L’uso di vfork() era complicato: per esempio, la non modifica dei dati nel processo padre dipendeva dal sapere quali variabili erano conservate in un registro.
4.3BSD, POSIX.1-2001. I requisiti indicati per vfork() dagli standard sono più deboli di quelli indicati per fork(2), così un’implementazione dove i due sono sinonimi è conforme. In particolare, il programmatore non può contare sul fatto che il padre rimanga bloccato fino a una chiamata di execve(2) o _exit(2), e non può contare su alcuno specifico comportamento riferendosi alla memoria condivisa.
Note Linux
I gestori dei fork stabiliti usando pthread_atfork(3) non sono chiamati quando un programma multithreaded che impiega le chiamate alla libreria di threading NPTL chiama vfork(). I gestori dei fork sono chiamati in questo caso in un programma che usi la libreria di threading LinuxThreads. (Vedere pthreads(7) per una descrizione delle librerie di threading di Linux).
Storia
La chiamata di sistema vfork() è apparsa nella 3.0BSD. Nella versione 4.4BSD è stata resa sinonimo di fork(2) ma NetBSD l’ha reintrodotta, cf. http://www.netbsd.org/Documentation/kernel/vfork.html . In Linux è stata equivalente a fork(2) fino alla versione 2.2.0-pre6. A partire dalla 2.2.0-pre9 (su i386, un po’ più tardi su altre architetture) è una chiamata di sistema indipendente. Ne è stato aggiunto il supporto in glibc 2.0.112.
È piuttosto sfortunato che Linux abbia richiamato questo spettro dal passato. La pagina di manuale di BSD afferma: "Questa chiamata di sistema sarà eliminata quando saranno implementati meccanismi appropriati di condivisione di sistema. Gli utenti non devono dipendere dalla semantica della condivisione di memoria di vfork() poiché sarebbe, in questo caso, resa sinonimo di fork(2)."
Dettagli sulla gestione del segnale sono oscuri e diversi da sistema a sistema. La pagina di manuale di BSD afferma: "Per evitare una possibile situazione di stallo, ai processi che sono figli nel mezzo di un vfork() non vengono mai inviati segnali SIGTTOU o SIGTTIN ; invece, output o ioctl sono permessi e i tentativi di input danno come risultato un’indicazione di fine file."