Mi ero dimenticato la nuova figura
[gapil.git] / prochand.tex
index 57ba6abf5fba57720b0bca5372436a964a23e805..09e1b59fbbd22c7bf9fa9eda3f1155c379fa193c 100644 (file)
@@ -970,18 +970,6 @@ versione 4.3 Reno di BSD, attualmente (con il kernel 2.4.x) i soli campi che
 sono mantenuti sono: \var{ru\_utime}, \var{ru\_stime}, \var{ru\_minflt},
 \var{ru\_majflt}, e \var{ru\_nswap}.
 
-\subsection{Le \textit{race condition}}
-\label{sec:proc_race_cond}
-
-Si definisce una \textit{race condition} il caso in cui diversi processi
-stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
-viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
-l'ordine di esecuzione di un processo, senza appositi meccanismi di
-sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
-fonti di errori molto subdoli, che possono verificarsi solo in condizioni
-particolari e quindi difficilmente riproducibili.
-
-
 \subsection{Le funzioni \texttt{exec}}
 \label{sec:proc_exec}
 
@@ -997,7 +985,7 @@ disco.
 Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
 famiglia di funzioni) che possono essere usate per questo compito, che in
 realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
-front-end a \func{execve}. Il prototipo  di quest'utiltima è:
+front-end a \func{execve}. Il prototipo  di quest'ultima è:
 
 \begin{prototype}{unistd.h}
 {int execve(const char * filename, char * const argv [], char * const envp[])}
@@ -1033,13 +1021,159 @@ front-end a \func{execve}. Il prototipo  di quest'utiltima 
 \end{prototype}
 
 Le altre funzioni della famiglia servono per fornire all'utente una serie
-possibile di diverse interfacce per la creazione di un nuovo processo. 
+possibile di diverse interfacce per la creazione di un nuovo processo. I loro
+prototipi sono:
+
+\begin{functions}
+\headdecl{unistd.h}
+\funcdecl{int execl(const char *path, const char *arg, ...)} 
+\funcdecl{int execv(const char *path, char *const argv[])} 
+\funcdecl{int execle(const char *path, const char *arg, ..., char 
+* const envp[])} 
+\funcdecl{int execlp(const char *file, const char *arg, ...)} 
+\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
+linea di comando e l'ambiente ricevuti dal nuovo processo.
+
+Queste funzioni ritornano solo in caso di errore, restituendo -1; nel qual
+caso \var{errno} andrà ad assumere i valori visti in precedenza per
+\func{execve}.
+\end{functions}
+
+Per capire meglio le differenze fra le funzioni della famiglia si può fare
+riferimento allo specchietto riportato in \ntab. 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 \var{argv} e \var{argc} visti
+dalla funzione \func{main} del programma chiamato). 
+
+Queste modalità sono due e sono riassunte dagli mnenonici \func{v} e \func{l}
+che stanno rispettivamente per \textit{vector} e \textit{list}. Nel primo caso
+gli argomenti sono passati tramite il vettore di puntatori \var{argv[]} a
+stringhe terminate con zero che costituiranno gli argomenti a riga di comando,
+questo vettore \emph{deve} essere terminato da un puntatore nullo.
+
+Nel secondo caso le stringhe degli argomenti sono passate alla funzione come
+lista di puntatori, nella forma:
+\begin{lstlisting}[labelstep=0,frame=,indent=1cm]{}
+  char * arg0, char * arg1,  ..., char * argn, NULL
+\end{lstlisting}
+che deve essere terminata da un puntatore nullo.  In entrambi i casi vale la
+convenzione che il primo argomento (\var{arg0} o \var{argv[0]}) viene usato
+per indicare il nome del file che contiene il programma che verrà eseguito.
+
+\begin{table}[!htb]
+  \footnotesize
+  \centering
+  \begin{tabular}[c]{|l|c|c|c||c|c|c|}
+    \hline
+    \multicolumn{1}{|c|}{\textbf{Caratteristiche}} & 
+    \multicolumn{6}{|c|}{\textbf{Funzioni}} \\
+    \hline
+    &\func{execl\ }&\func{execlp}&\func{execle}
+    &\func{execv\ }& \func{execvp}& \func{execve} \\
+    \hline
+    \hline
+    argomenti a lista    &$\bullet$&$\bullet$&$\bullet$&&& \\
+    argomenti a vettore  &&&&$\bullet$&$\bullet$&$\bullet$\\
+    \hline
+    filename completo    &&$\bullet$&&&$\bullet$& \\ 
+    ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
+    \hline
+    ambiente a vettore   &&&$\bullet$&&&$\bullet$ \\
+    uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
+    \hline
+  \end{tabular}
+  \caption{Confronto delle caratteristiche delle varie funzioni della 
+    famiglia \func{exec}.}
+  \label{tab:proc_exec_scheme}
+\end{table}
+
+La seconda differenza fra le funzioni riguarda le modalità con cui si
+specifica il programma che si vuole eseguire. Con lo mnemonico \func{p} si
+indicano le due funzioni che replicano il comportamento della shell nello
+specificare il comando da eseguire; quando il parametro \var{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
+viene posto in esecuzione è il primo che viene trovato. Se si ha un errore di
+permessi negati (cioè l'esecuzione della sottostante \func{execve} ritorna un
+\macro{EACCESS}), la ricerca viene proseguita nelle eventuali ulteriori
+directory indicate nel \var{PATH}, solo se non viene trovato nessun altro file
+viene finalmente restituito \macro{EACCESS}.
+
+Le altre quattro funzioni si limitano invece a cercare di eseguire il file
+indicato dal parametro \var{path}, che viene interpretato come il
+\textit{pathname} del programma.
+
+\begin{figure}[htb]
+  \centering
+  \includegraphics[width=8cm]{img/exec_rel.eps}
+  \caption{La inter-relazione fra le sei funzioni della famiglia \func{exec}}
+  \label{fig:proc_exec_relat}
+\end{figure}
+
+
+La terza differenza è come viene passata la lista delle variabili di ambiente.
+Con lo mnemonico \func{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 \macro{NULL}), le altre usano il
+valore della variabile \var{environ} (vedi \secref{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;
+la lista completa è la seguente:
+\begin{itemize}
+\item il \textit{process ID} (\acr{pid}) ed il \textit{parent process ID}
+  (\acr{ppid}).
+\item il \textit{real user ID} ed il \textit{real group ID} (vedi
+  \secref{sec:proc_user_group}).
+\item i \textit{supplementary group ID} (vedi \secref{sec:proc_user_group}).
+\item il \textit{session ID} ed il \textit{process group ID} (vedi
+  \secref{sec:sess_xxx}).
+\item il terminale di controllo (vedi \secref{sec:sess_xxx}).
+\item il tempo restante ad un allarme.
+\item la directory radice e la directory di lavoro corrente (vedi
+  \secref{sec:file_work_dir}).
+\item la maschera di creazione dei file (\var{umask}, vedi
+  \secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
+  \secref{sec:file_xxx}).
+\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
+  \secref{sec:sig_xxx}).
+\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
+\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
+  \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+\end{itemize}
+
+Oltre a questo i segnali che sono stati settati per essere ignorati nel
+processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
+gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+può anche non essere resettatto a \macro{SIG\_DFL} (si veda
+\secref{sec:sig_xxx}).
+
+La gestione dei file aperti dipende dal valore del flag di
+\textit{close-on-exec} per ciascun file descriptor (si veda
+\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+altri file restano aperti. Questo significa che il comportamento di default è
+che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
+esplicita a \func{fcntl} che setti il suddetto flag.
+
+Per le directory lo standard POSIX.1 richiede che esse vengano chiuse, in
+genere questo è fatto automaticamente dalla funzione \func{opendir} che
+effettua il settaggio del flag in maniera trasparente all'utente.
+
+
 
 
-Con \func{exec} si chiude il cerchio delle funzioni su cui si basa il
-controllo dei processi in unix: con \func{fork} si crea un nuovo processo, con
-\func{exec} si avvia un nuovo programma, con \func{exit} e \func{wait} si
-effettua e si gestisce la conclusione dei programmi.
+Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
+basato il controllo dei processi in unix: con \func{fork} si crea un nuovo
+processo, con \func{exec} si avvia un nuovo programma, con \func{exit} e
+\func{wait} si effettua e si gestisce la conclusione dei programmi. Tutte le
+altre funzioni sono ausiliarie e servono la lettura e il settaggio dei vari
+parametri connessi ai processi.
 
 
 \section{Il controllo di accesso}
@@ -1066,6 +1200,7 @@ dall'utente che ha lanciato il processo (attraverso i valori di \acr{uid} e
 \acr{gid}), e vengono usati sia per il controllo di accesso ai file che per la
 gestione dei privilegi associati ai processi stessi.
 \begin{table}[htb]
+  \footnotesize
   \centering
   \begin{tabular}[c]{|c|l|p{8cm}|}
     \hline
@@ -1126,3 +1261,16 @@ per tener conto di eventuali \acr{suid} o \acr{sgid}.
 \subsection{Le funzioni \texttt{seteuid} e \texttt{setegid}}
 \label{sec:proc_seteuid}
 
+
+\subsection{Le \textit{race condition}}
+\label{sec:proc_race_cond}
+
+Si definisce una \textit{race condition} il caso in cui diversi processi
+stanno cercando di fare qualcosa con una risorsa comune ed il risultato finale
+viene a dipendere dall'ordine di esecuzione dei medesimi. Ovviamente dato che
+l'ordine di esecuzione di un processo, senza appositi meccanismi di
+sincronizzazione, non è assolutamente prevedibile, queste situazioni sono
+fonti di errori molto subdoli, che possono verificarsi solo in condizioni
+particolari e quindi difficilmente riproducibili.
+
+