Perché dobbiamo creare fork per creare nuovi processi?

In Unix ogni volta che vogliamo creare un nuovo processo, eseguiamo il fork del processo corrente, creando un nuovo processo figlio che è esattamente lo stesso del processo padre; quindi eseguiamo una chiamata di sistema exec per sostituire tutti i dati dal processo padre con quelli per il nuovo processo.

Perché in primo luogo creiamo una copia del processo genitore e non creiamo direttamente un nuovo processo?

La risposta breve è, forkè in Unix perché all'epoca era facile adattarsi al sistema esistente e perché un sistema precedente a Berkeley aveva usato il concetto di forcelle.

Da The Evolution of the Unix Time-sharing System (è stato evidenziato il testo pertinente ):

Il controllo di processo nella sua forma moderna è stato progettato e implementato in un paio di giorni. È sorprendente quanto facilmente si inserisse nel sistema esistente; allo stesso tempo è facile vedere come alcune delle caratteristiche leggermente insolite del design siano presenti proprio perché rappresentavano piccole modifiche facilmente codificabili a ciò che esisteva . Un buon esempio è la separazione delle funzioni fork e exec. Il modello più comune per la creazione di nuovi processi prevede la specifica di un programma per l'esecuzione del processo; in Unix, un processo a fork continua a eseguire lo stesso programma del suo genitore fino a quando non esegue un exec esplicito. La separazione delle funzioni non è certamente unica per Unix, e infatti era presente nel sistema di condivisione del tempo Berkeley, che era ben noto a Thompson. Tuttavia, sembra ragionevole supporre che esista in Unix principalmente a causa della facilità con cui il fork potrebbe essere implementato senza cambiare molto altro . Il sistema gestiva già più processi (ovvero due); c'era una tabella dei processi e i processi sono stati scambiati tra la memoria principale e il disco. È richiesta solo l'implementazione iniziale di fork

1) Espansione della tabella dei processi

2) Aggiunta di una chiamata fork che ha copiato il processo corrente nell'area di scambio del disco, usando le primitive IO di scambio già esistenti e apportato alcune modifiche alla tabella del processo.

In effetti, il fork call del PDP-7 ha richiesto esattamente 27 righe di codice assembly. Naturalmente, erano necessari altri cambiamenti nel sistema operativo e nei programmi utente, e alcuni di essi erano piuttosto interessanti e inaspettati. Ma un fork-exec combinato sarebbe stato notevolmente più complicato , se non altro perché exec in quanto tale non esisteva; la sua funzione era già stata eseguita, usando IO esplicito, dalla shell.

Da quel momento, Unix si è evoluto. forkseguito da execnon è più l'unico modo per eseguire un programma.

• vfork è stato creato per essere un fork più efficiente nel caso in cui il nuovo processo intenda eseguire un exec subito dopo il fork. Dopo aver eseguito un vfork, i processi padre e figlio condividono lo stesso spazio dati e il processo padre viene sospeso fino a quando il processo figlio non esegue un programma o esce.

• posix_spawn crea un nuovo processo ed esegue un file in una singola chiamata di sistema. Prende una serie di parametri che consentono di condividere selettivamente i file aperti del chiamante e di copiarne la disposizione del segnale e altri attributi nel nuovo processo.

[Ripeterò parte della mia risposta da qui .]

Perché non avere semplicemente un comando che crea un nuovo processo da zero? Non è assurdo e inefficiente copiarne uno che verrà sostituito immediatamente?

In effetti, probabilmente non sarebbe altrettanto efficiente per alcuni motivi:

1. La "copia" prodotta da fork()è un po 'di un'astrazione, dal momento che il kernel usa un copy-on-write del sistema ; tutto ciò che deve davvero essere creato è una mappa di memoria virtuale. Se la copia chiama immediatamente exec(), la maggior parte dei dati che sarebbero stati copiati se fosse stata modificata dall'attività del processo non deve mai essere effettivamente copiata / creata perché il processo non fa nulla che richieda il suo utilizzo.

2. Vari aspetti significativi del processo figlio (ad esempio, il suo ambiente) non devono essere duplicati individualmente o impostati sulla base di un'analisi complessa del contesto, ecc. Si presume che siano gli stessi di quelli del processo chiamante e questo è il sistema abbastanza intuitivo che conosciamo.

Per spiegare un po 'di più il numero 1, la memoria che viene "copiata" ma a cui non si accede successivamente non viene mai realmente copiata, almeno nella maggior parte dei casi. Un'eccezione in questo contesto potrebbe essere se si è proceduto a un fork di un processo, quindi il processo padre è stato chiuso prima che il figlio si sostituisse exec(). Dico che potrebbe essere perché la maggior parte dei genitori potrebbe essere memorizzata nella cache se c'è abbastanza memoria libera, e non sono sicuro di quanto questo sarebbe sfruttato (che dipenderebbe dall'implementazione del sistema operativo).

Ovviamente, ciò non rende in superficie più efficiente l' uso di una copia rispetto all'utilizzo di una lavagna vuota, tranne per il fatto che "la lavagna vuota" non è letteralmente nulla e deve comportare un'allocazione. Il sistema potrebbe avere un modello di processo vuoto / nuovo generico che copia allo stesso modo, ¹ ma che quindi non salverebbe realmente nulla rispetto al fork di copia su scrittura. Quindi il n. 1 dimostra solo che l'utilizzo di un "nuovo" processo vuoto non sarebbe più efficiente.

Il punto 2 spiega perché l'uso della forcella è probabilmente più efficiente. L'ambiente di un bambino viene ereditato dal suo genitore, anche se è un eseguibile completamente diverso. Ad esempio, se il processo padre è una shell e il figlio un browser Web $HOMEè sempre lo stesso per entrambi, ma poiché entrambi potrebbero successivamente modificarlo, devono essere due copie separate. Quello nel bambino è prodotto dall'originale fork().

^{1. Una strategia che potrebbe non avere molto senso letterale, ma il mio punto è che la creazione di un processo implica più che copiare la sua immagine in memoria dal disco.}

Penso che il motivo per cui Unix abbia avuto solo la forkfunzione di creare nuovi processi sia il risultato della filosofia Unix

Costruiscono una funzione che fa bene una cosa. Crea un processo figlio.

Ciò che si fa con il nuovo processo spetta quindi al programmatore. Può usare una delle exec*funzioni e avviare un programma diverso, oppure non può usare exec e usare le due istanze dello stesso programma, il che può essere utile.

Quindi puoi ottenere un maggior grado di libertà da quando puoi usarlo

1. fork senza exec *
2. fork con exec * o
3. solo exec * senza fork

e in aggiunta è sufficiente memorizzare i forke le exec*chiamate di funzione, che nel 1970 si doveva fare.

Esistono due filosofie della creazione di processi: fork con l'eredità e creazione con argomenti. Unix usa fork, ovviamente. (OSE, ad esempio, e VMS utilizzano il metodo di creazione.) Unix ha MOLTE caratteristiche ereditabili e altre vengono aggiunte periodicamente. Tramite l'ereditarietà, queste nuove caratteristiche possono essere aggiunte SENZA MODIFICARE I PROGRAMMI ESISTENTI! Utilizzando un modello di creazione con argomenti, aggiungere nuove caratteristiche significherebbe aggiungere nuovi argomenti alla chiamata di creazione. Il modello Unix è più semplice.

Offre inoltre l'utilissimo modello fork-without-exec, in cui un processo può dividersi in più pezzi. Ciò era di vitale importanza quando non esisteva alcuna forma di I / O asincrono ed è utile quando si utilizzano più CPU in un sistema. (Pre-thread.) L'ho fatto molto nel corso degli anni, anche di recente. In sostanza, consente di containerizzare più "programmi" in un singolo programma, quindi non c'è assolutamente spazio per corruzione o disallineamenti di versione, ecc.

Il modello fork / exec offre anche la possibilità per un bambino specifico di ereditare un ambiente radicalmente strano, impostato tra fork e exec. Cose come i descrittori di file ereditati, in particolare. (Un'estensione di stdio fd's.) Il modello di creazione non offre la possibilità di ereditare tutto ciò che non è stato immaginato dai creatori della chiamata di creazione.

Alcuni sistemi possono anche supportare la compilazione dinamica di codice nativo, in cui il processo sta in effetti scrivendo il proprio programma in codice nativo. In altre parole, vuole un nuovo programma che sta scrivendo al volo, SENZA dover passare attraverso il ciclo codice sorgente / compilatore / linker e occupare spazio su disco. (Credo che ci sia un sistema di linguaggio Verilog che lo fa.) Il modello fork supporta questo, il modello creato normalmente non lo farebbe.

La funzione fork () non è solo per copiare il processo padre, ma restituisce un valore che indica che il processo è il processo padre o figlio, l'immagine sotto spiega come utilizzare fork () come padre e un figlio:

come mostrato quando il processo è il padre fork () restituisce l'ID del processo figlio PID altrimenti restituisce0

ad esempio puoi utilizzarlo se hai un processo (web server) che riceve le richieste e su ogni richiesta crea un son processprocesso per elaborare questa richiesta, qui il padre e i suoi figli hanno lavori diversi.

Quindi, nessuna esecuzione di una copia di un processo non è la cosa esatta come fork ().

Il reindirizzamento degli I / O viene implementato più facilmente dopo il fork e prima di exec. Il bambino, consapevole del fatto che è il bambino, può chiudere i descrittori di file, aprirne di nuovi, dup () o dup2 () per ottenerli sul giusto numero fd, ecc., Senza influire sul genitore. Dopo averlo fatto, e forse qualsiasi modifica della variabile d'ambiente desiderata (anche senza influire sul genitore), può eseguire il nuovo programma nell'ambiente su misura.

Penso che tutti qui sappiano come funziona il fork, ma la domanda è: perché dobbiamo creare un duplicato esatto del genitore usando fork? Risposta ==> Prendi un esempio di server (senza fork), mentre client-1 sta accedendo al server, se allo stesso tempo è arrivato il secondo client-2 e vuole accedere al server ma il server non dà l'autorizzazione al nuovo arrivato client-2 perché il server è occupato a servire client-1, quindi client-2 deve attendere. Dopo che tutti i servizi al client-1 sono terminati, client-2 è ora in grado di accedere al server. Adesso considera se allo stesso tempo client-3 arriva, quindi client-3 deve attendere fino al termine di tutti i servizi al client-2. Prendi lo scenario in cui le migliaia di client devono accedere al server contemporaneamente ... quindi tutti i client devono aspetta (il server è occupato !!).

Questo viene evitato creando (usando fork) una copia duplicata esatta (cioè figlio) del server, dove ogni figlio (che è una copia duplicata esatta del suo genitore cioè server) è dedicato al client appena arrivato, quindi contemporaneamente tutti i client accedono allo stesso server.