\subsection{L'architettura della gestione dei processi}
\label{sec:proc_hierarchy}
-A differenza di quanto avviene in altri sistemi, ad esempio nel VMS la
+A differenza di quanto avviene in altri sistemi, ad esempio nel VMS, dove la
generazione di nuovi processi è un'operazione privilegiata, una delle
caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è
che qualunque processo può a sua volta generarne altri. Ogni processo è
identificato presso il sistema da un numero univoco, il cosiddetto
-\textit{Process ID} o, più brevemente, \ids{PID}, assegnato in forma
+\textit{Process ID}, o più brevemente \ids{PID}, assegnato in forma
progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
Una seconda caratteristica di un sistema unix-like è che la generazione di un
Una terza caratteristica del sistema è che ogni processo è sempre stato
generato da un altro processo, il processo generato viene chiamato
\textit{processo figlio} (\textit{child process}) mentre quello che lo ha
-viene chiamato \textsl{processo padre} (\textit{parent process}). Questo vale
-per tutti i processi, con una sola eccezione, dato che ci deve essere un punto
-di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}),
-che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato
-dal kernel alla conclusione della fase di avvio. Essendo questo il primo
-processo lanciato dal sistema ha sempre il \ids{PID} uguale a 1 e non è figlio
-di nessun altro processo.
-
-Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far
-partire tutti gli altri processi necessari al funzionamento del sistema,
+generato viene chiamato \textsl{processo padre} (\textit{parent
+ process}). Questo vale per tutti i processi, con una sola eccezione; dato
+che ci deve essere un punto di partenza esiste un processo iniziale (che
+normalmente è \cmd{/sbin/init}), che come accennato in
+sez.~\ref{sec:intro_kern_and_sys} viene lanciato dal kernel alla conclusione
+della fase di avvio. Essendo questo il primo processo lanciato dal sistema ha
+sempre \ids{PID} uguale a 1 e non è figlio di nessun altro processo.
+
+Ovviamente \cmd{init} è un processo particolare che in genere si occupa di
+lanciare tutti gli altri processi necessari al funzionamento del sistema,
inoltre \cmd{init} è essenziale per svolgere una serie di compiti
amministrativi nelle operazioni ordinarie del sistema (torneremo su alcuni di
essi in sez.~\ref{sec:proc_termination}) e non può mai essere terminato. La
questa tabella, costituita da una struttura \kstruct{task\_struct}, che
contiene tutte le informazioni rilevanti per quel processo. Tutte le strutture
usate a questo scopo sono dichiarate nell'\textit{header file}
-\file{linux/sched.h}, ed uno schema semplificato, che riporta la struttura
-delle principali informazioni contenute nella \texttt{task\_struct} (che in
-seguito incontreremo a più riprese), è mostrato in
-fig.~\ref{fig:proc_task_struct}.
+\file{linux/sched.h}, ed in fig.~\ref{fig:proc_task_struct} si è riportato uno
+schema semplificato che mostra la struttura delle principali informazioni
+contenute nella \texttt{task\_struct}, che in seguito incontreremo a più
+riprese.
\begin{figure}[!htb]
\centering \includegraphics[width=14cm]{img/task_struct}
dell'energia da parte del processore che può essere messo in stato di
sospensione anche per lunghi periodi di tempo.
-Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
+Ma, indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
viene eseguito lo \textit{scheduler} effettua il calcolo delle priorità dei
vari processi attivi (torneremo su questo in sez.~\ref{sec:proc_priority}) e
stabilisce quale di essi debba essere posto in esecuzione fino alla successiva
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
-\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
+\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t}, che in genere è un
intero con segno (nel caso di Linux e della \acr{glibc} il tipo usato è
\ctyp{int}).
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\label{sec:proc_fork}
-La funzione di sistema \funcd{fork} è la funzione fondamentale della gestione
+La funzione di sistema \func{fork} è la funzione fondamentale della gestione
dei processi: come si è detto tradizionalmente l'unico modo di creare un nuovo
processo era attraverso l'uso di questa funzione,\footnote{in realtà oggi la
\textit{system call} usata da Linux per creare nuovi processi è \func{clone}
migliore interazione coi \textit{thread}.} essa quindi riveste un ruolo
centrale tutte le volte che si devono scrivere programmi che usano il
multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei
- \textit{thread} che tratteremo al cap.~\ref{cha:threads}, è in parte minore,
- ma \func{fork} resta comunque la funzione principale per la creazione di
- processi.} Il prototipo della funzione è:
+ \textit{thread}\unavref{ che tratteremo al cap.~\ref{cha:threads}}, è in
+ parte minore, ma \func{fork} resta comunque la funzione principale per la
+ creazione di processi.} Il prototipo di \funcd{fork} è:
\begin{funcproto}{
\fhead{unistd.h}
\fdecl{pid\_t fork(void)}
\fdesc{Crea un nuovo processo.}
}
-{La funzione ritorna il \ids{PID} del figlio al padre e $0$ al figlio in caso
- di successo e $-1$ al padre senza creare il figlio per un errore,
- nel qual caso \var{errno} assumerà uno dei valori:
+
+{La funzione ritorna in caso di successo il \ids{PID} del figlio nel padre e
+ $0$ nel figlio mentre ritorna $-1$ nel padre, senza creare il figlio, per un
+ errore, al caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EAGAIN}] non ci sono risorse sufficienti per creare un altro
processo (per allocare la tabella delle pagine e le strutture del task) o
\end{funcproto}
Dopo il successo dell'esecuzione di una \func{fork} sia il processo padre che
-il processo figlio continuano ad essere eseguiti normalmente a partire
+il processo figlio continuano ad essere eseguiti normalmente, a partire
dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
del padre, e riceve una copia dei segmenti di testo, dati e dello
\textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo
due volte, una nel padre e una nel figlio.
La scelta di questi valori di ritorno non è casuale, un processo infatti può
-avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli
-permette di identificare quello appena creato. Al contrario un figlio ha
-sempre un solo padre, il cui \ids{PID} può sempre essere ottenuto con
-\func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il
-valore nullo, che non è il \ids{PID} di nessun processo.
+avere più figli, ed il valore di ritorno di \func{fork} è l'unico che gli
+permette di identificare qual è quello appena creato. Al contrario un figlio
+ha sempre un solo padre il cui \ids{PID}, come spiegato in
+sez.~\ref{sec:proc_pid}, può sempre essere ottenuto con \func{getppid}; per
+questo si ritorna un valore nullo, che non è il \ids{PID} di nessun processo.
Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci
sono già troppi processi nel sistema, il che di solito è sintomo che
\textit{client-server} è illustrato in sez.~\ref{sec:net_cliserv}) in cui il
padre riceve ed accetta le richieste da parte dei programmi client, per
ciascuna delle quali pone in esecuzione un figlio che è incaricato di fornire
-il servizio.
+le risposte associate al servizio.
La seconda modalità è quella in cui il processo vuole eseguire un altro
programma; questo è ad esempio il caso della shell. In questo caso il processo
\func{sleep}) per il padre ed il figlio (con \cmd{forktest -h} si ottiene la
descrizione delle opzioni). Il codice completo, compresa la parte che gestisce
le opzioni a riga di comando, è disponibile nel file \file{fork\_test.c},
-distribuito insieme agli altri sorgenti degli esempi su
-\url{http://gapil.truelite.it/gapil_source.tgz}.
+distribuito insieme agli altri sorgenti degli esempi della guida su
+\url{http://gapil.gnulinux.it}.
Decifrato il numero di figli da creare, il ciclo principale del programma
(\texttt{\small 24-40}) esegue in successione la creazione dei processi figli
risultati precedenti infatti sono stati ottenuti usando un kernel della
serie 2.4.} Questa è una ottimizzazione adottata per evitare che il padre,
effettuando per primo una operazione di scrittura in memoria, attivasse il
-meccanismo del \textit{copy on write}, operazione inutile qualora il figlio
-venga creato solo per eseguire una \func{exec} su altro programma che scarta
-completamente lo spazio degli indirizzi e rende superflua la copia della
-memoria modificata dal padre. Eseguendo sempre per primo il figlio la
-\func{exec} verrebbe effettuata subito, con la certezza di utilizzare
+meccanismo del \textit{copy on write}, operazione inutile quando il figlio
+viene creato solo per eseguire una \func{exec} per lanciare un altro programma
+che scarta completamente lo spazio degli indirizzi e rende superflua la copia
+della memoria modificata dal padre. Eseguendo sempre per primo il figlio la
+\func{exec} verrebbe effettuata subito, con la certezza di utilizzare il
\textit{copy on write} solo quando necessario.
Con il kernel 2.6.32 però il comportamento è stato nuovamente cambiato,
stavolta facendo eseguire per primo sempre il padre. Si è realizzato infatti
-che l'eventualità prospettata per la scelta precedente era comunque molto
-improbabile, mentre l'esecuzione immediata del padre presenta sempre il
+che l'eventualità prospettata per la scelta precedente era comunque poco
+probabile, mentre l'esecuzione immediata del padre presenta sempre il
vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
-della CPU e nella unità di gestione della memoria virtuale senza doverli
+della CPU e nell'unità di gestione della memoria virtuale, senza doverli
invalidare, cosa che per i processori moderni, che hanno linee di cache
interne molto profonde, avrebbe un forte impatto sulle prestazioni.
Allora anche se quanto detto in precedenza vale come comportamento effettivo
dei programmi soltanto per i kernel fino alla serie 2.4, per mantenere la
portabilità con altri kernel unix-like, e con i diversi comportamenti adottati
-dalle Linux nelle versioni successive, è opportuno non fare affidamento su
-nessun tipo comportamento predefinito e non dare per assunta l'esecuzione
-preventiva del padre o del figlio.
-
-Si noti poi come dopo la \func{fork}, essendo i segmenti di memoria utilizzati
-dai singoli processi completamente indipendenti, le modifiche delle variabili
-nei processi figli, come l'incremento di \var{i} in (\texttt{\small 31}), sono
-visibili solo a loro, (ogni processo vede solo la propria copia della
-memoria), e non hanno alcun effetto sul valore che le stesse variabili hanno
-nel processo padre ed in eventuali altri processi figli che eseguano lo stesso
-codice.
+dalle Linux nella sua evoluzione, è comunque opportuno non fare affidamento su
+nessun tipo di comportamento predefinito e non fare assunzioni sull'ordine di
+esecuzione di padre e figlio.
+
+Si noti infine come dopo la \func{fork}, essendo i segmenti di memoria
+utilizzati dai singoli processi completamente indipendenti, le modifiche delle
+variabili nei processi figli, come l'incremento di \var{i} in (\texttt{\small
+ 31}), sono visibili solo a loro, (ogni processo vede solo la propria copia
+della memoria), e non hanno alcun effetto sul valore che le stesse variabili
+hanno nel processo padre ed in eventuali altri processi figli che eseguano lo
+stesso codice.
Un secondo aspetto molto importante nella creazione dei processi figli è
quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
in gran dettaglio in sez.~\ref{sec:file_unix_interface} per l'interfaccia
nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
-adottata nelle librerie del linguaggio C e valida per qualunque sistema
-operativo.
+adottata nelle librerie del linguaggio C, valida per qualunque sistema
+operativo.
Qui basta accennare che si sono usate le funzioni standard della libreria del
C che prevedono l'output bufferizzato. Il punto è che questa bufferizzazione
(che tratteremo in dettaglio in sez.~\ref{sec:file_buffering}) varia a seconda
che si tratti di un file su disco, in cui il buffer viene scaricato su disco
solo quando necessario, o di un terminale, in cui il buffer viene scaricato ad
-ogni carattere di a capo.
+ogni carattere di ``a capo''.
Nel primo esempio allora avevamo che, essendovi un a capo nella stringa
stampata, ad ogni chiamata a \func{printf} il buffer veniva scaricato, per cui
tutti i figli. La funzione \func{fork} infatti ha la caratteristica di
duplicare nei processi figli tutti i \textit{file descriptor} (vedi
sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
-in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il
-che comporta che padre e figli condividono le stesse voci della \textit{file
- table} (tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
-sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione corrente nel
-file.
-
-In questo modo se un processo scrive su un file aggiornerà la posizione
-corrente sulla \textit{file table}, e tutti gli altri processi, che vedono la
-stessa \textit{file table}, vedranno il nuovo valore. In questo modo si evita,
-in casi come quello appena mostrato in cui diversi processi scrivono sullo
-stesso file, che l'output successivo di un processo vada a sovrapporsi a
-quello dei precedenti: l'output potrà risultare mescolato, ma non ci saranno
-parti perdute per via di una sovrascrittura.
+in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}). Ciò
+fa si che padre e figli condividano le stesse voci della \textit{file table}
+(tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
+sez.~\ref{sec:file_shared_access}) fra le quali c'è anche la posizione
+corrente nel file.
+
+Quando un processo scrive su un file la posizione corrente viene aggiornata
+sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
+\textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
+casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
+file, che l'output di un processo successivo vada a sovrapporsi a quello dei
+precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
+perdute per via di una sovrascrittura.
Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
% LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps
% LocalWords: sid thread Ingo Molnar ppid getpid getppid sys unistd LD threads
-% LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM
+% LocalWords: void tempnam pathname sibling cap errno EAGAIN ENOMEM context
% LocalWords: stack read only copy write tab client spawn forktest sleep PATH
% LocalWords: source LIBRARY scheduling race condition printf descriptor dup
% LocalWords: close group session tms lock vfork execve BSD stream main abort
% LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
-% LocalWords: list environ NULL umask utime cutime ustime fcntl linker
+% LocalWords: list environ NULL umask utime cutime ustime fcntl linker Posix
% LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
% LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr
% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
% LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND
% LocalWords: capability capget capset header ESRCH undef version obj clear PT
-% LocalWords: pag ssize length proc capgetp preemptive cache runnable contest
+% LocalWords: pag ssize length proc capgetp preemptive cache runnable
% LocalWords: SIGSTOP soft slice nice niceness counter which SC switch side
% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO COUNT
% LocalWords: yield Robin setscheduler policy param OTHER priority setparam to
% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID panic
% LocalWords: loader EISDIR SIGTRAP uninterrutible killable EQUAL sizeof XOR
% LocalWords: destset srcset ALLOC num cpus setsize emacs pager getty TID
+% LocalWords: reaper SUBREAPER Library futex
%%% Local Variables:
%%% mode: latex
projects / gapil.git / blobdiff