Provided by: manpages-it_3.73-2_all 
NOME
vfork - crea un processo figlio e blocca il genitore
SINTASSI
#include <sys/types.h>
#include <unistd.h>
pid_t vfork(void);
Macro per test di funzionalità per glibc (vedere feature_test_macros(7)):
vfork():
Since glibc 2.12:
_BSD_SOURCE ||
(_XOPEN_SOURCE >= 500 ||
_XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED) &&
!(_POSIX_C_SOURCE >= 200809L || _XOPEN_SOURCE >= 700)
Before glibc 2.12:
_BSD_SOURCE || _XOPEN_SOURCE >= 500 || _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
DESCRIZIONE
Descrizione standard
(Da POSIX.1) 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 genitore. 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 thread viene sospeso finché il figlio non
termina (sia normalmente, chiamando _exit(2), che in modo anormale, dopo aver consegnato
un segnale fatal), o finchè non esegue una chiamata a execve(2). Fino a quel punto, il
figlio condivide la memoria con il genitore, incluso lo stack. Il figlio non deve tornare
dalla funzione attuale o chiamare exit(3), ma può chiamare _exit(2).
Come in fork(2), il processo figlio creato da vfork() eredita copie di diversi attributi
del processo del chiamante (per esempio, descrittori di file, definizioni di segnale e la
directory di lavoro corrente); la chiamata vfork() differisce solo nel trattamento dello
spazio degli indirizzi virtuali, come sopra descritto.
I segnali inviati al genitore arrivano dopo che il figlio ha rilasciato la memoria del
genitore (cioé dopo che il figlio termina o chiama execve(2)).
Descrizione storica
Sotto Linux, fork(2) è implementato usando pagine 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 genitore, 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 genitore, ma prendeva la memoria del genitore e il thread di controllo fino a una
chiamata a execve(2) o un exit. Il processo genitore era sospeso mentre il figlio
utilizzava le sue risorse. L'uso di vfork() era complicato: per esempio, la non modifica
dei dati nel processo genitore dipendeva dal sapere quali variabili erano conservate in un
registro.
CONFORME A
4.3BSD; POSIX.1-2001 (ma segnato come OBSOLETO). POSIX.1-2008 rimuove le specifiche per
vfork(). 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 genitore rimanga bloccato
fino al termine del figlio o finché chiama execve(2), e non può contare su alcuno
specifico comportamento riferendosi alla memoria condivisa.
NOTE
Alcuni considerano la semantica di vfork() come un difetto dell'architettura, e la pagina
di manuale di 4.2BSD dichiarava: "Questa chiamata di sistema verrà eliminata quando
saranno implementati opportuni meccanismi di condivisione. Gli utenti non dovrebbero
dipendere dalla semantica di condivisione della memoria di vfork() poiché, in questo caso,
diventerebbe sinonimo di fork(2)." Comunque, anche se il moderno hardware per la gestione
della memoria ha ridotto la differenza fra fork(2) e vfork(), ci sono diverse ragioni per
le quali Linux e altri sistemi hanno mantenuto vfork():
* Alcune applicazioni per cui le prestazioni sono un punto critico richiedono il piccolo
vantaggio in termini di prestazioni garantito da vfork().
* vfork() può essere implementato su sistemi mancanti di un'unità di gestione della
memoria (MMU), sui quali però fork(2) non può essere implementato. (POSIX.1-2008 ha
rimosso vfork() dallo standard; nelle motivazioni di POSIX per la funzione
posix_spawn(3) si nota che questa funzione, che fornisce una funzionalità equivalente a
fork(2)+exec(3), è progettata per essere implementabile su sistemi mancanti di MMU).
Note Linux
I gestori di fork definiti 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 usa la libreria di
threading LinuxThreads. (Vedere pthreads(7) per una descrizione delle librerie di
threading di Linux).
Una chiamata a vfork() è equivalente a una chiamata a clone(2) con opzioni definite come:
CLONE_VM | CLONE_VFORK | SIGCHLD
Storia
La chiamata di sistema vfork() è apparsa nella 3.0BSD. Nella versione 4.4BSD è diventata
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.
BUG
I 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 ioctls sono permessi e i tentativi di input danno come risultato
un'indicazione di fine file."
VEDERE ANCHE
clone(2), execve(2), fork(2), unshare(2), wait(2)
COLOPHON
Questa pagina fa parte del rilascio 3.73 del progetto Linux man-pages. Una descrizione
del progetto, le istruzioni per la segnalazione degli errori, e l'ultima versione di
questa pagina si trova su http://www.kernel.org/doc/man-pages/.
La versione italiana fa parte del pacchetto man-pages-it v. 3.73, a cura di: ILDP "Italian
Linux Documentation Project" http://www.pluto.it/ildp
Per la traduzione in italiano si può fare riferimento a
http://www.pluto.it/ildp/collaborare/
Segnalare eventuali errori di traduzione a ildp@pluto.it