\cmd{init} o da uno dei suoi figli\footnote{in realtà questo non è del tutto
vero, in Linux ci sono alcuni processi speciali che pur comparendo come
figli di \cmd{init}, o con \acr{pid} successivi, sono in realtà generati
- direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, etc.).} si
+ direttamente dal kernel, (come \cmd{keventd}, \cmd{kswapd}, ecc.).} si
possono classificare i processi con la relazione padre/figlio in
un'organizzazione gerarchica ad albero, in maniera analoga a come i file sono
organizzati in un albero di directory (si veda
descrizione delle opzioni); il codice completo, compresa la parte che gestisce
le opzioni a riga di comando, è disponibile nel file \file{ForkTest.c},
distribuito insieme agli altri sorgenti degli esempi su
-\href{http://gapil.firenze.linux.it/gapil_source.tgz}
-{\texttt{http://gapil.firenze.linux.it/gapil\_source.tgz}}.
+\href{http://gapil.truelite.it/gapil_source.tgz}
+{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
Decifrato il numero di figli da creare, il ciclo principale del programma
(\texttt{\small 24--40}) esegue in successione la creazione dei processi figli
nella variabile puntata da \param{status} e tutte le risorse del kernel
relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
-figlio) permette di identificare qual'è quello che è uscito.
+figlio) permette di identificare qual è quello che è uscito.
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
Linux, seguendo un'estensione di BSD, supporta altre due funzioni per la
lettura dello stato di terminazione di un processo, analoghe alle precedenti
-ma che prevedono un ulteriore parametro attraverso il quale il kernel può
+ma che prevedono un ulteriore argomento attraverso il quale il kernel può
restituire al padre informazioni sulle risorse usate dal processo terminato e
dai vari figli. Le due funzioni sono \funcd{wait3} e \funcd{wait4}, che
diventano accessibili definendo la macro \macro{\_USE\_BSD}; i loro prototipi
\funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
* rusage)}
- È identica a \func{waitpid} sia per comportamento che per i valori dei
- parametri, ma restituisce in \param{rusage} un sommario delle risorse usate
+ È identica a \func{waitpid} sia per comportamento che per i valori degli
+ argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
dal processo.
\funcdecl{pid\_t wait3(int *status, int options, struct rusage *rusage)}
\funcdecl{int execvp(const char *file, char *const argv[])}
Sostituiscono l'immagine corrente del processo con quella indicata nel primo
-argomento. I parametri successivi consentono di specificare gli argomenti a
+argomento. Gli argomenti successivi consentono di specificare gli argomenti a
linea di comando e l'ambiente ricevuti dal nuovo processo.
\bodydesc{Queste funzioni ritornano solo in caso di errore, restituendo -1;
Per capire meglio le differenze fra le funzioni della famiglia si può fare
riferimento allo specchietto riportato in tab.~\ref{tab:proc_exec_scheme}. La
-prima differenza riguarda le modalità di passaggio dei parametri che poi
-andranno a costituire gli argomenti a linea di comando (cioè i valori di
+prima differenza riguarda le modalità di passaggio dei valori che poi andranno
+a costituire gli argomenti a linea di comando (cioè i valori di
\param{argv} e \param{argc} visti dalla funzione \func{main} del programma
chiamato).
La seconda differenza fra le funzioni riguarda le modalità con cui si
specifica il programma che si vuole eseguire. Con lo mnemonico \code{p} si
indicano le due funzioni che replicano il comportamento della shell nello
-specificare il comando da eseguire; quando il parametro \param{file} non
-contiene una ``\file{/}'' esso viene considerato come un nome di programma, e
-viene eseguita automaticamente una ricerca fra i file presenti nella lista di
-directory specificate dalla variabile di ambiente \var{PATH}. Il file che
+specificare il comando da eseguire; quando l'argomento \param{file} non
+contiene una ``\texttt{/}'' esso viene considerato come un nome di programma,
+e viene eseguita automaticamente una ricerca fra i file presenti nella lista
+di directory specificate dalla variabile di ambiente \var{PATH}. Il file che
viene posto in esecuzione è il primo che viene trovato. Se si ha un errore
relativo a permessi di accesso insufficienti (cioè l'esecuzione della
sottostante \func{execve} ritorna un \errcode{EACCES}), la ricerca viene
\end{figure}
La terza differenza è come viene passata la lista delle variabili di ambiente.
-Con lo mnemonico \code{e} vengono indicate quelle funzioni che necessitano di
-un vettore di parametri \var{envp[]} analogo a quello usato per gli argomenti
-a riga di comando (terminato quindi da un \val{NULL}), le altre usano il
-valore della variabile \var{environ} (vedi sez.~\ref{sec:proc_environ}) del
-processo di partenza per costruire l'ambiente.
+Con lo mnemonico \texttt{e} vengono indicate quelle funzioni che necessitano
+di un vettore di parametri \var{envp[]} analogo a quello usato per gli
+argomenti a riga di comando (terminato quindi da un \val{NULL}), le altre
+usano il valore della variabile \var{environ} (vedi
+sez.~\ref{sec:proc_environ}) del processo di partenza per costruire
+l'ambiente.
Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da
\func{exec} assume anche una serie di altre proprietà del processo chiamante;
si applica alla seconda per i group-ID. I processi non privilegiati possono
cambiare uno qualunque degli user-ID solo ad un valore corrispondente o
all'user-ID reale, o a quello effettivo o a quello salvato, l'amministratore
-può specificare i valori che vuole; un valore di -1 per un qualunque parametro
+può specificare i valori che vuole; un valore di -1 per un qualunque argomento
lascia inalterato l'identificatore corrispondente.
Per queste funzioni esistono anche due controparti che permettono di leggere
projects / gapil.git / blobdiff