-La necessità di avere uno \textit{stack} alternativo c'è solo quando si
-intende creare un \textit{thread}, in tal caso infatti il nuovo \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 \func{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 di doversi garantire contro la evidente possibilità di
-\textit{race condition} che questa situazione comporta (vedi
-sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
-necessario che il chiamante allochi preventivamente un'area di memoria. In
-genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
-imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
-non utilizzarlo direttamente nel processo chiamante.
-
-In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
-non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
-presente inoltre che in molte architetture di processore 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 da 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 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 (è sottinteso
-cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
-in questo caso si applica la semantica del \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}, la \acr{glibc} definisce una funzione di
-libreria con una sintassi diversa, orientata a questo scopo, e la
-\textit{system call} resta accessibile solo se invocata esplicitamente come
-visto in sez.~\ref{sec:proc_syscall}.\footnote{ed inoltre per questa
- \textit{system call} non è disponibile la chiamata veloce con
- \texttt{vsyscall}.} La funzione di libreria si chiama semplicemente
-\funcd{clone} ed il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sched.h}
-\fdecl{int clone(int (*fn)(void *), void *child\_stack, int flags, void *arg,
- ... \\
-\phantom{int clone(}/* pid\_t *ptid, struct user\_desc *tls, pid\_t *ctid */ )}
-\fdesc{Crea un nuovo processo o \textit{thread}.}
-}
-{La funzione ritorna il \textit{Thread ID} assegnato al nuovo processo in caso
- di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
- valori:
-\begin{errlist}
- \item[\errcode{EAGAIN}] sono già in esecuzione troppi processi.
- \item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
- un valore nullo per \param{child\_stack}.
- \item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
- \texttt{task\_struct} o per copiare le parti del contesto del chiamante
- necessarie al nuovo \textit{task}.
- \item[\errcode{EPERM}] non si hanno i privilegi di amministratore
- richiesti dai flag indicati.
-\end{errlist}}
-\end{funcproto}
-
-% NOTE: una pagina con la descrizione degli argomenti:
-% * http://www.lindevdoc.org/wiki/Clone
-
-La funzione prende come primo argomento \param{fn} il puntatore alla funzione
-che verrà messa in esecuzione nel nuovo processo, che può avere un unico
-argomento di tipo puntatore a \ctyp{void}, il cui valore viene passato dal
-terzo argomento \param{arg}. Per quanto il precedente prototipo possa
-intimidire nella sua espressione, in realtà l'uso è molto semplice basterà
-definire una qualunque funzione \param{fn} che restituisce un intero ed ha
-come argomento un puntatore a \ctyp{void}, e \code{fn(arg)} sarà eseguita in
-un nuovo processo.
-
-Il nuovo processo resterà in esecuzione fintanto che la funzione \param{fn}
-non ritorna, o esegue \func{exit} o viene terminata da un segnale. Il valore
-di ritorno della funzione (o quello specificato con \func{exit}) verrà
-utilizzato come stato di uscita della funzione. I tre
-argomenti \param{ptid}, \param{tls} e \param{ctid} sono opzionali e sono
-presenti solo a partire dal kernel 2.6 e sono stati aggiunti come supporto per
-le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix
- Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono
-utilizzati soltanto se si sono specificati rispettivamente i flag
-\const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e
-\const{CLONE\_CHILD\_SETTID}.
-
-La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
-\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
-al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
-un processo ordinario e non un \textit{thread}.
-
-Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
-nuovo processo da essa creato, è controllato principalmente
-dall'argomento \param{flags}, che deve essere specificato come maschera
-binaria, ottenuta con un OR aritmetico di una delle costanti del seguente
-elenco, che illustra quelle attualmente disponibili:\footnote{si fa
- riferimento al momento della stesura di questa sezione, cioè con il kernel
- 3.2.}
-
-\begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
-
-\item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
- ID} posto all'indirizzo dato dall'argomento \param{ctid}, eseguendo un
- riattivazione del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a
- quell'indirizzo. Questo flag viene utilizzato dalla librerie di gestione dei
- \textit{thread} ed è presente dal kernel 2.5.49.
-
-\item[\constd{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
- figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
- utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
- kernel 2.5.49.
-
-\item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
- padre la \textit{file descriptor table} (vedi sez.~\ref{sec:file_fd}),
- questo significa che ogni \textit{file descriptor} aperto da un processo
- verrà visto anche dall'altro e che ogni chiusura o cambiamento dei
- \textit{file descriptor flag} di un \textit{file descriptor} verrà per
- entrambi.
-
- Se non viene impostato il processo figlio eredita una copia della
- \textit{file descriptor table} del padre e vale la semantica classica della
- gestione dei \textit{file descriptor}, che costituisce il comportamento
- ordinario di un sistema unix-like e che illustreremo in dettaglio in
- sez.~\ref{sec:file_shared_access}.
-
-\item[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
- condividerà con il padre le informazioni relative all'albero dei file, ed in
- particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
- stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
- \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
- qualunque di queste caratteristiche in un processo, avrà effetto anche
- sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
- informazioni, che saranno così indipendenti per i due processi, come avviene
- nel comportamento ordinario di un sistema unix-like.
-
-\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo processo
- condividerà con il padre il contesto dell'I/O, altrimenti, come avviene nel
- comportamento ordinario con una \func{fork} otterrà un suo contesto
- dell'I/O.
-
- Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
- sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
- questi vengono trattati come se fossero lo stesso, condividendo il tempo per
- l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
- questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
- dello stesso processo (ad esempio con le funzioni di I/O asincrono di
- sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
-
-%TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
-%relativa sezione da creare a parte
-
-% \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
-% introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
-% processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
-% di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
-% di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
-% tutti quegli oggetti che non vegono identificati con un \textit{pathname}
-% sull'albero dei file.
-
-% L'uso di questo flag richiede privilegi di amministratore (più precisamente
-% la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
-% con \const{CLONE\_SYSVSEM}.
-
-% \item[\constd{CLONE\_NEWNET}]
-% \item[\constd{CLONE\_NEWNS}]
-% \item[\constd{CLONE\_NEWPID}]
-% \item[\constd{CLONE\_NEWUTS}]