\label{sec:process_clone}
La funzione tradizionale con cui creare un nuovo processo in un sistema
-Unix-like è, come illustrato in sez.~\ref{sec:proc_fork}, \func{fork}, ma con
+Unix-like, come illustrato in sez.~\ref{sec:proc_fork}, è \func{fork}, ma con
l'introduzione del supporto del kernel per i \textit{thread} (vedi
cap.~\ref{cha:threads}), si è avuta la necessità di una interfaccia che
consentisse un maggiore controllo sulla modalità con cui vengono creati nuovi
processi, che poi è stata utilizzata anche per fornire ulteriore supporto per
-le varie tecnologie di virtualizzazione dei processi (i cosidetti
+le tecnologie di virtualizzazione dei processi (i cosidetti
\textit{container}).
-Per far questo l'interfaccia per la creazione di un nuovo processo è stata
-implementata una nuova \textit{system call}, \texttt{sys\_clone}, che consente
-di reimplementare anche la tradizionale \func{fork}. La \textit{system call}
-richiede due argomenti, \param{flags}, che consente di controllare le modalità
-di creazione del nuovo processo e \param{child\_stack}, che deve essere
-indicato se si intende creare un \textit{thread} in cui la memoria viene
-condivisa fra il processo chiamante ed il nuovo processo creato. L'esecuzione
-del programma creato da \param{child\_stack} riprende, come per \func{fork},
-da dopo l'esecuzione della stessa.
+Per questo l'interfaccia per la creazione di un nuovo processo è stata
+delegata ad una nuova \textit{system call}, \texttt{sys\_clone}, che consente
+di reimplementare anche la tradizionale \func{fork}. In realtà in questo caso
+più che di nuovi processi si può parlare della creazioni di nuovi
+``\textit{task}'' del kernel che possono assumere la veste sia di un processo
+vero e proprio come quelli trattati finora, che di un \textit{thread}, come
+quelli che vedremo in sez.~\ref{sec:linux_thread}, in cui la memoria viene
+condivisa fra il processo chiamante ed il nuovo processo creato. Per evitare
+confusione fra \textit{thread} e processi ordinari, abbiamo deciso di usare la
+nomenclatura \textit{task} per indicare la unità di esecuzione generica messa
+a disposizione del kernel che \texttt{sys\_clone} permette di creare.
+
+La \textit{system call} richiede soltanto due argomenti: il
+primo, \param{flags}, consente di controllare le modalità di creazione del
+nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
+dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
+indicato quando si intende creare un \textit{thread}. L'esecuzione del
+programma creato da \param{child\_stack} riprende, come per \func{fork}, da
+dopo l'esecuzione della stessa.
La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
-processo vede esattamente la stessa memoria del processo chiamante, e nella
-sua esecuzione andrebbe a scrivere sullo \textit{stack} usato anche da questi,
-il che comporterebbe immediatamente la presenza di \itindex{race~condition}
-\textit{race conditions} all'esecuzione di una funzione da parte di entrambi
+\textit{task} vede esattamente la stessa memoria del \textit{task}
+``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
+ il \textit{task} che ha eseguito \texttt{sys\_clone} rispetto al
+ \textit{task} da essa creato, senza nessuna delle implicazioni che il
+ concetto ha per i processi.} e nella sua esecuzione alla prima chiamata di
+una funzione andrebbe a scrivere sullo \textit{stack} usato anche dal padre
(si ricordi quanto visto in sez.~\ref{sec:proc_mem_layout} riguardo all'uso
-dello \textit{stack}).
-
-Per evitare questo è allora necessario che il chiamante allochi
-preventivamente un'area di memoria (in genere lo si fa con una \func{malloc})
-che la funzione imposterà come \textit{stack} del nuovo processo, avendo
-ovviamente cura di non utilizzarla direttamente. Si tenga presente inoltre che
-in molte architetture lo \textit{stack} cresce verso il basso, pertanto in tal
-caso non si dovrà specificare per \param{child\_stack} il puntatore restituito
-da \func{malloc}, ma un puntatore alla fine del buffer con essa allocato.
-
-Dato che tutto ciò serve solo per i \textit{thread} che condividono la
+dello \textit{stack}).
+
+Per evitare di doversi garantire contro la evidente possibilità di
+\itindex{race~condition} \textit{race conditions} che questa situazione
+comporta è necessario che il chiamante allochi preventivamente un'area di
+memoria (in genere lo si fa con una \func{malloc}) che la funzione imposterà
+come \textit{stack} del nuovo processo, avendo ovviamente cura di non
+utilizzarla direttamente. In questo modo i due \textit{task} avranno degli
+\textit{stack} indipendenti e non si dovranno affrontare problematiche di
+\itindex{race~condition} \textit{race conditions}. Si tenga presente inoltre
+che in molte architetture lo \textit{stack} cresce verso il basso, pertanto in
+tal caso non si dovrà specificare per \param{child\_stack} il puntatore
+restituito da \func{malloc}, ma un puntatore alla fine del buffer con essa
+allocato.
+
+Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
memoria, la \textit{system call}, a differenza della funzione di libreria che
-vedremo a breve, consente anche di passare il valore \val{NULL}
-per \param{child\_stack}, nel qual caso si applicherà la semantica del
-\itindex{copy-on-write} \textit{copy on write} illustrata in
-sez.~\ref{sec:proc_fork}, le pagine dello \textit{stack} verranno
-automaticamente copiate come le altre e il nuovo processo avrà un suo
-\textit{stack}.
+vedremo a breve, consente anche di passare per \param{child\_stack} il valore
+\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
+processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
+ sottinteso cioè che non si stia usando il flag \const{CLONE\_VM}.} ed in
+questo caso si applica la semantica del \itindex{copy-on-write} \textit{copy
+ on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le pagine dello
+\textit{stack} verranno automaticamente copiate come le altre e il nuovo
+processo avrà un suo \textit{stack} totalmente indipendente da quello del
+padre.
+
+Dato che l'uso principale della nuova \textit{system call} è quello relativo
+alla creazione dei \textit{thread}, le \acr{glibc} definiscono una funzione di
+libreria
+\funcd{clone}
\subsection{La funzione \func{prctl}}
fornisce una interfaccia generica per tutte le operazioni specialistiche. La
funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
standardizzata ed è specifica di Linux, anche se ne esiste una analoga in
- IRIX, è stata introdotta con il kernel 2.1.57.}
+ IRIX; è stata introdotta con il kernel 2.1.57.}
\begin{functions}
\headdecl{sys/prctl.h}
projects / gapil.git / commitdiff