\fdesc{Esegue la \textit{system call} indicata da \param{number}.}
}
{La funzione ritorna un intero dipendente dalla \textit{system call} invocata,
-in generale $0$ indica il successo e un valore negativo un errore.}
+ in generale $0$ indica il successo ed un valore negativo un errore.}
\end{funcproto}
La funzione richiede come primo argomento il numero della \textit{system call}
La funzione è pensata per eseguire una conclusione pulita di un programma che
usi la libreria standard del C; essa esegue tutte le funzioni che sono state
registrate con \func{atexit} e \func{on\_exit} (vedi
-sez.~\ref{sec:proc_atexit}), chiude tutti gli stream effettuando il
-salvataggio dei dati sospesi (chiamando \func{fclose}, vedi
-sez.~\ref{sec:file_fopen}), infine passa il controllo al kernel chiamando la
-\textit{system call} \func{\_exit} (che vedremo a breve) che completa la
-terminazione del processo.
+sez.~\ref{sec:proc_atexit}), chiude tutti i \textit{file stream} (vedi
+sez.~\ref{sec:file_stream}) effettuando il salvataggio dei dati sospesi
+(chiamando \func{fclose}, vedi sez.~\ref{sec:file_fopen}), infine passa il
+controllo al kernel chiamando la \textit{system call} \func{\_exit} (che
+vedremo a breve) che completa la terminazione del processo.
\itindbeg{exit~status}
Anche se l'argomento \param{status} (ed il valore di ritorno di \func{main})
sono numeri interi di tipo \ctyp{int}, si deve tener presente che il valore
-dello stato di uscita viene comunque troncato ad 8 bit, per cui deve essere
-sempre compreso fra 0 e 255. Si tenga presente che se si raggiunge la fine
-della funzione \func{main} senza ritornare esplicitamente si ha un valore di
-uscita indefinito, è pertanto consigliabile di concludere sempre in maniera
-esplicita detta funzione.
+dello stato di uscita viene comunque troncato ad 8 bit,
+per cui deve essere sempre compreso fra 0 e 255. Si tenga presente che se si
+raggiunge la fine della funzione \func{main} senza ritornare esplicitamente si
+ha un valore di uscita indefinito, è pertanto consigliabile di concludere
+sempre in maniera esplicita detta funzione.
Non esiste un valore significato intrinseco della stato di uscita, ma una
convenzione in uso pressoché universale è quella di restituire 0 in caso di
La funzione termina immediatamente il processo e le eventuali funzioni
registrate con \func{atexit} e \func{on\_exit} non vengono eseguite. La
funzione chiude tutti i file descriptor appartenenti al processo, cosa che
-però non comporta il salvataggio dei dati eventualmente presenti nei buffer
-degli stream, (torneremo sulle due interfacce dei file a partire da
-cap.~\ref{cha:file_intro}). Infine fa sì che ogni figlio del processo sia
-adottato da \cmd{init} (vedi cap.~\ref{cha:process_handling}), manda un
-segnale \signal{SIGCHLD} al processo padre (vedi
+però non comporta il salvataggio dei dati eventualmente presenti nei buffer di
+\textit{file stream}, (torneremo sulle due interfacce dei file in
+cap.~\ref{cha:files_std_interface} e
+cap.~\ref{cha:file_unix_interface})). Infine fa sì che ogni figlio del
+processo sia adottato da \cmd{init} (vedi sez.~\ref{sec:proc_termination}),
+manda un segnale \signal{SIGCHLD} al processo padre (vedi
sez.~\ref{sec:sig_job_control}) e ritorna lo stato di uscita specificato
in \param{status} che può essere raccolto usando la funzione \func{wait} (vedi
sez.~\ref{sec:proc_wait}).
\begin{funcproto}{ \fhead{stdlib.h} \fdecl{void (*function)(void)}
\fdesc{Registra la funzione \param{function} per la chiamata all'uscita
- dal programma.} } {La funzione restituisce $0$ in caso di successo e
- $-1$ in caso di fallimento, \var{errno} non viene modificata.}
+ dal programma.} } {La funzione ritorna $0$ in caso di successo e
+ $-1$ per un errore, \var{errno} non viene modificata.}
\end{funcproto}
La funzione richiede come argomento \param{function} l'indirizzo di una
\fhead{stdlib.h}
\fdecl{void (*function)(int , void *), void *arg)}
\fdesc{Registra la funzione \param{function} per la chiamata all'uscita dal
- programma.} }{La funzione restituisce $0$ in caso di successo e $-1$ in caso
-di fallimento, \var{errno} non viene modificata.}
+ programma.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, \var{errno}
+ non viene modificata.}
\end{funcproto}
In questo caso la funzione da chiamare all'uscita prende i due argomenti
indipendentemente dalla funzione usata per farla.
Una volta completata l'esecuzione di tutte le funzioni registrate verranno
-chiusi tutti gli stream aperti ed infine verrà chiamata \func{\_exit} per la
-terminazione del programma. Questa è la sequenza ordinaria, eseguita a meno
-che una delle funzioni registrate non esegua al suo interno \func{\_exit}, nel
-qual caso la terminazione del programma sarà immediata ed anche le successive
-funzioni registrate non saranno invocate.
+chiusi tutti i \textit{file stream} aperti ed infine verrà chiamata
+\func{\_exit} per la terminazione del programma. Questa è la sequenza
+ordinaria, eseguita a meno che una delle funzioni registrate non esegua al suo
+interno \func{\_exit}, nel qual caso la terminazione del programma sarà
+immediata ed anche le successive funzioni registrate non saranno invocate.
Se invece all'interno di una delle funzioni registrate si chiama un'altra
volta \func{exit} lo standard POSIX.1-2001 prescrive un comportamento
\fhead{stdlib.h}
\fdecl{void *realloc(void *ptr, size\_t size)}
\fdesc{Cambia la dimensione di un'area di memoria precedentemente allocata.}
-} {La funzione restituisce il puntatore alla zona di memoria allocata in caso
- di successo e \val{NULL} in caso di fallimento, nel qual caso \var{errno}
+} {La funzione ritorna il puntatore alla zona di memoria allocata in caso
+ di successo e \val{NULL} per un errore, nel qual caso \var{errno}
assumerà il valore \errval{ENOMEM}.}
\end{funcproto}
\fdecl{void *alloca(size\_t size)}
\fdesc{Alloca un'area di memoria nello \textit{stack}.}
}
-{La funzione restituisce il puntatore alla zona di memoria allocata, in caso
- di fallimento il comportamento è indefinito.}
+{La funzione ritorna il puntatore alla zona di memoria allocata, in caso
+ di errore il comportamento è indefinito.}
\end{funcproto}
La funzione alloca la quantità di memoria (non inizializzata) richiesta
\fdecl{int brk(void *addr)}
\fdesc{Sposta la fine del segmento dati del processo.}
}
-{La funzione restituisce 0 in caso di successo e $-1$ in caso di fallimento,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà il valore \errval{ENOMEM}.}
\end{funcproto}
\fdecl{void *sbrk(intptr\_t increment)}
\fdesc{Incrementa la dimensione del segmento dati del processo.}
}
-{La funzione restituisce il puntatore all'inizio della nuova zona di memoria
- allocata in caso di successo e \val{NULL} in caso di fallimento, nel qual
+{La funzione ritorna il puntatore all'inizio della nuova zona di memoria
+ allocata in caso di successo e \val{NULL} per un errore, nel qual
caso \var{errno} assumerà il valore \errval{ENOMEM}.}
\end{funcproto}
nuovo indirizzo finale dello stesso. L'argomento è definito come di tipo
\type{intptr\_t}, ma a seconda della versione delle librerie e del sistema può
essere indicato con una serie di tipi equivalenti come \type{ptrdiff\_t},
-\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzone
+\type{ssize\_t}, \ctyp{int}. Se invocata con un valore nullo la funzione
permette di ottenere l'attuale posizione della fine del \index{segmento!dati}
segmento dati.
versioni di kernel unix-like;\footnote{nel caso di Linux devono essere
comunque definite le macro \macro{\_BSD\_SOURCE} e \macro{\_SVID\_SOURCE}.}
il suo prototipo è:
-% \begin{functions}
-% \headdecl{unistd.h}
-% \headdecl{sys/mman.h}
-
-% \funcdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
-% Ritorna lo stato delle pagine di memoria occupate da un processo.
-
-% \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di
-% errore, nel qual caso \var{errno} assumerà uno dei valori:
-% \begin{errlist}
-% \item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
-% della memoria usata dal processo o l'intervallo di indirizzi specificato
-% non è mappato.
-% \item[\errcode{EINVAL}] \param{addr} non è un multiplo delle dimensioni di
-% una pagina.
-% \item[\errcode{EFAULT}] \param{vec} punta ad un indirizzo non valido.
-% \item[\errcode{EAGAIN}] il kernel è temporaneamente non in grado di fornire
-% una risposta.
-% \end{errlist}
-% }
-% \end{functions}
\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int mincore(void *addr, size\_t length, unsigned char *vec)}
\fdesc{Ritorna lo stato delle pagine di memoria occupate da un processo.}
}
-{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore, nel qual
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOMEM}] o \param{addr} + \param{length} eccede la dimensione
\fdecl{int mcheck(void (*abortfn) (enum mcheck\_status status))}
\fdesc{Attiva i controlli di consistenza delle allocazioni di memoria.}
}
-{La funzione restituisce $0$ in caso di successo e $-1$ in caso di fallimento;
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errorre;
\var{errno} non viene impostata.}
\end{funcproto}
\textbf{Valore} & \textbf{Significato} \\
\hline
\hline
- \macro{MCHECK\_OK} & riportato a \func{mprobe} se nessuna
+ \const{MCHECK\_OK} & riportato a \func{mprobe} se nessuna
inconsistenza è presente.\\
- \macro{MCHECK\_DISABLED}& riportato a \func{mprobe} se si è chiamata
+ \const{MCHECK\_DISABLED}& riportato a \func{mprobe} se si è chiamata
\func{mcheck} dopo aver già usato
\func{malloc}.\\
- \macro{MCHECK\_HEAD} & i dati immediatamente precedenti il buffer sono
+ \const{MCHECK\_HEAD} & i dati immediatamente precedenti il buffer sono
stati modificati, avviene in genere quando si
decrementa eccessivamente il valore di un
puntatore scrivendo poi prima dell'inizio del
buffer.\\
- \macro{MCHECK\_TAIL} & i dati immediatamente seguenti il buffer sono
+ \const{MCHECK\_TAIL} & i dati immediatamente seguenti il buffer sono
stati modificati, succede quando si va scrivere
oltre la dimensione corretta del buffer.\\
- \macro{MCHECK\_FREE} & il buffer è già stato disallocato.\\
+ \const{MCHECK\_FREE} & il buffer è già stato disallocato.\\
\hline
\end{tabular}
\caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
\fdecl{enum mcheck\_status mprobe(ptr)}
\fdesc{Esegue un controllo di consistenza delle allocazioni.}
}
-{La funzione restituisce un codice fra quelli riportati in
- tab.\ref{tab:mcheck_status_value} e non ha errori.}
+{La funzione ritorna un codice fra quelli riportati in
+ tab.~\ref{tab:mcheck_status_value} e non ha errori.}
\end{funcproto}
La funzione richiede che si passi come argomento un puntatore ad un blocco di
\subsection{Le variabili di ambiente}
\label{sec:proc_environ}
+\index{variabili!di~ambiente|(}
Oltre agli argomenti passati a linea di comando esiste un'altra modalità che
permette di trasferire ad un processo delle informazioni in modo da
modificarne il comportamento. Ogni processo infatti riceve dal sistema, oltre
\end{figure}
Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
-\textsl{\texttt{nome=valore}} ed in questa forma che le funzioni di gestione
+\textsl{\texttt{NOME=valore}} ed in questa forma che le funzioni di gestione
che vedremo a breve se le aspettano, se pertanto si dovesse costruire
manualmente un ambiente si abbia cura di rispettare questa convenzione.
Inoltre alcune variabili, come quelle elencate in
\fdesc{Cerca una variabile di ambiente del processo.}
}
{La funzione ritorna il puntatore alla stringa contenente il valore della
- variabile di ambiente in caso di successo e \val{NULL} in caso di errore.}
+ variabile di ambiente in caso di successo e \val{NULL} per un errore.}
\end{funcproto}
La funzione effettua una ricerca nell'ambiente del processo cercando una
\fdecl{int putenv(char *string)}
\fdesc{Inserisce, modifica o rimuove una variabile d'ambiente.}
}
-{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore, che può
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, che può
essere solo \errval{ENOMEM}.}
\end{funcproto}
all'ambiente, se invece esiste il suo valore sarà impostato a quello
specificato dal contenuto di \param{string} (nel caso \texttt{valore}). Se
invece si passa come argomento solo il nome di una variabile di ambiente
-(cioè \param{string} è nella forma ``\texttt{NAME}'' e non contiene il
+(cioè \param{string} è nella forma ``\texttt{NOME}'' e non contiene il
carattere ``\texttt{=}'') allora questa, se presente nell'ambiente, verrà
cancellata.
dal prototipo.} pertanto ogni cambiamento alla stringa in questione si
riflette automaticamente sull'ambiente, e quindi si deve evitare di passare a
questa funzione una \index{variabili!automatiche} variabile automatica (per
-evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}).
+evitare i problemi esposti in sez.~\ref{sec:proc_var_passing}). Benché non sia
+richiesto dallo standard nelle versioni della \acr{glibc} a partire dalla 2.1
+la funzione è rientrante (vedi sez.~\ref{sec:proc_reentrant}).
Infine quando una chiamata a \func{putenv} comporta la necessità di creare una
nuova versione del vettore \var{environ} questo sarà allocato automaticamente,
un'allocazione fatta in precedenza da un'altra \func{putenv}. Questo avviene
perché il vettore delle variabili di ambiente iniziale, creato dalla chiamata
ad \func{exec} (vedi sez.~\ref{sec:proc_exec}) è piazzato nella memoria al di
-sopra dello \itindex{stack} stack, (vedi fig.~\ref{fig:proc_mem_layout}) e non
-nello \itindex{heap} \textit{heap} e quindi non può essere deallocato.
-Inoltre la memoria associata alle variabili di ambiente eliminate non viene
-liberata.
+sopra dello \itindex{stack} \textit{stack}, (vedi
+fig.~\ref{fig:proc_mem_layout}) e non nello \itindex{heap} \textit{heap} e
+quindi non può essere deallocato. Inoltre la memoria associata alle variabili
+di ambiente eliminate non viene liberata.
Come alternativa a \func{putenv} si può usare la funzione \funcd{setenv} che
però consente solo di aggiungere o modificare una variabile di ambiente; il
\fdecl{int setenv(const char *name, const char *value, int overwrite)}
\fdesc{Inserisce o modifica una variabile di ambiente.}
}
-{La funzione ritorna 0 in caso di successo e $-1$ per un errore,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per aggiungere una nuova
\fdecl{int unsetenv(const char *name)}
\fdesc{Rimuove una variabile di ambiente.}
}
-{La funzione ritorna 0 in caso di successo e $-1$ per un errore,
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] \param{name} è \val{NULL} o una stringa di lunghezza
nulla o che contiene il carattere ``\texttt{=}''.
- \end{errlist}}
+\end{errlist}}
\end{funcproto}
La funzione richiede soltanto il nome della variabile di ambiente
\acr{glibc} successive la 2.2.2, per le precedenti \func{unsetenv} era
definita come \texttt{void} e non restituiva nessuna informazione.}
-L'ultima funzione per la gestione dell'ambiente è \funcd{clearenv}, che viene
-usata per cancellare completamente tutto l'ambiente; il suo prototipo è:
+L'ultima funzione per la gestione dell'ambiente è
+\funcd{clearenv},\footnote{che come accennato è l'unica non presente nello
+ standard POSIX.1-2000, ed è disponibili solo per versioni della \acr{glibc}
+ a partire dalla 2.0; per poterla utilizzare occorre aver definito le macro
+ \macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE}.} che viene usata per
+cancellare completamente tutto l'ambiente; il suo prototipo è:
+\begin{funcproto}{
+\fhead{stdlib.h}
+\fdecl{int clearenv(void)}
+\fdesc{Cancella tutto l'ambiente.}
+}
+{La funzione ritorna $0$ in caso di successo e un valore diverso da zero per
+ un errore.}
+\end{funcproto}
In genere si usa questa funzione in maniera precauzionale per evitare i
problemi di sicurezza connessi nel trasmettere ai programmi che si invocano un
-ambiente che può contenere dei dati non controllati. In tal caso si provvede
-alla cancellazione di tutto l'ambiente per costruirne una versione
-``\textsl{sicura}'' da zero.
+ambiente che può contenere dei dati non controllati, le cui variabili possono
+causare effetti indesiderati. Con l'uso della funzione si provvede alla
+cancellazione di tutto l'ambiente originale in modo da poterne costruirne una
+versione ``\textsl{sicura}'' da zero.
+
+\index{variabili!di~ambiente|)}
\subsection{La localizzazione}
\ctyp{int}. Un tipo \textit{self-promoting} è un tipo che verrebbe promosso
a sé stesso.} il che esclude vettori, puntatori a funzioni e interi di tipo
\ctyp{char} o \ctyp{short} (con segno o meno). Una restrizione ulteriore di
-alcuni compilatori è di non dichiarare l'ultimo argomento fisso come
-\direct{register}.\footnote{la direttiva \direct{register} del compilatore
- chiede che la variabile dichiarata tale sia mantenuta, nei limiti del
- possibile, all'interno di un registro del processore; questa direttiva è
- originaria dell'epoca dai primi compilatori, quando stava al programmatore
- scrivere codice ottimizzato, riservando esplicitamente alle variabili più
- usate l'uso dei registri del processore, oggi questa direttiva è in disuso
- dato che tutti i compilatori sono normalmente in grado di valutare con
- maggior efficacia degli stessi programmatori quando sia il caso di eseguire
- questa ottimizzazione.}
+alcuni compilatori è di non dichiarare l'ultimo argomento fisso come variabile
+di tipo \direct{register}.\footnote{la direttiva \direct{register} del
+ compilatore chiede che la variabile dichiarata tale sia mantenuta, nei
+ limiti del possibile, all'interno di un registro del processore; questa
+ direttiva è originaria dell'epoca dai primi compilatori, quando stava al
+ programmatore scrivere codice ottimizzato, riservando esplicitamente alle
+ variabili più usate l'uso dei registri del processore, oggi questa direttiva
+ è in disuso pressoché completo dato che tutti i compilatori sono normalmente
+ in grado di valutare con maggior efficacia degli stessi programmatori quando
+ sia il caso di eseguire questa ottimizzazione.}
Una volta dichiarata la funzione il secondo passo è accedere ai vari argomenti
quando la si va a definire. Gli argomenti fissi infatti hanno un loro nome, ma
\textit{self-promoting}.
In generale è perfettamente legittimo richiedere meno argomenti di quelli che
-potrebbero essere stati effettivamente forniti, e nella esecuzione delle
+potrebbero essere stati effettivamente forniti, per cui nella esecuzione delle
\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
-saranno ignorati. Se invece si richiedono più argomenti di quelli forniti si
-otterranno dei valori indefiniti, si avranno risultati indefiniti anche quando
-si chiama \macro{va\_arg} specificando un tipo che non corrisponde a quello
-usato per il corrispondente argomento.
+saranno ignorati. Se invece si richiedono più argomenti di quelli
+effettivamente forniti si otterranno dei valori indefiniti. Si avranno
+risultati indefiniti anche quando si chiama \macro{va\_arg} specificando un
+tipo che non corrisponde a quello usato per il corrispondente argomento.
Infine una volta completata l'estrazione occorre indicare che si sono concluse
le operazioni con la macro \macro{va\_end}, la cui definizione è:
quei tipi di dati, in genere usati da una libreria, la cui struttura interna
non deve essere vista dal programma chiamante (da cui deriva il nome opaco)
che li devono utilizzare solo attraverso dalle opportune funzioni di
-gestione. Per questo motivo non può essere assegnata direttamente ad un'altra
-variabile dello stesso tipo. Per risolvere questo problema lo standard ISO
-C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo posto
- \macro{\_\_va\_copy} che era il nome proposto in una bozza dello standard.}
-ha previsto una macro ulteriore che permette di eseguire la copia di una lista
-degli argomenti:
+gestione.
+
+Per questo motivo una variabile di tipo \type{va\_list} non può essere
+assegnata direttamente ad un'altra variabile dello stesso tipo, ma lo standard
+ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo
+ posto \macro{\_\_va\_copy} che era il nome proposto in una bozza dello
+ standard.} ha previsto una macro ulteriore che permette di eseguire la
+copia di una lista degli argomenti:
{\centering
\begin{funcbox}{
dei medesimi occorrerà tenerne conto (ad esempio un \ctyp{char} verrà visto da
\macro{va\_arg} come \ctyp{int}).
-Uno dei problemi che si devono affrontare con le funzioni con un numero
+Un altro dei problemi che si devono affrontare con le funzioni con un numero
variabile di argomenti è che non esiste un modo generico che permetta di
-stabilire quanti sono gli argomenti passati effettivamente in una chiamata.
+stabilire quanti sono gli argomenti effettivamente passati in una chiamata.
Esistono varie modalità per affrontare questo problema; una delle più
immediate è quella di specificare il numero degli argomenti opzionali come uno
degli argomenti fissi. Una variazione di questo metodo è l'uso di un argomento
-per specificare anche il tipo degli argomenti (come fa la stringa di formato
-per \func{printf}).
+fisso per specificare anche il tipo degli argomenti variabili, come fa la
+stringa di formato per \func{printf} (vedi sez.~\ref{sec:file_formatted_io}).
-Una modalità diversa, che può essere applicata solo quando il tipo degli
-argomenti lo rende possibile, è quella che prevede di usare un valore speciale
-come ultimo argomento (come fa ad esempio \func{execl} che usa un puntatore
-\val{NULL} per indicare la fine della lista degli argomenti).
+Infine una ulteriore modalità diversa, che può essere applicata solo quando il
+tipo degli argomenti lo rende possibile, è quella che prevede di usare un
+valore speciale per l'ultimo argomento, come fa ad esempio \func{execl} che
+usa un puntatore \val{NULL} per indicare la fine della lista degli argomenti
+(vedi sez.~\ref{sec:proc_exec}).
\subsection{Il controllo di flusso non locale}
Il controllo del flusso di un programma in genere viene effettuato con le
varie istruzioni del linguaggio C; fra queste la più bistrattata è il
-\code{goto}, che viene deprecato in favore dei costrutti della programmazione
-strutturata, che rendono il codice più leggibile e mantenibile. Esiste però un
-caso in cui l'uso di questa istruzione porta all'implementazione più
-efficiente e più chiara anche dal punto di vista della struttura del
-programma: quello dell'uscita in caso di errore.
+\instruction{goto}, che viene deprecato in favore dei costrutti della
+programmazione strutturata, che rendono il codice più leggibile e
+mantenibile. Esiste però un caso in cui l'uso di questa istruzione porta
+all'implementazione più efficiente e più chiara anche dal punto di vista della
+struttura del programma: quello dell'uscita in caso di errore.
\index{salto~non-locale|(}
Tutto ciò può essere realizzato proprio con un salto non-locale; questo di
norma viene realizzato salvando il contesto dello \itindex{stack}
\textit{stack} nel punto in cui si vuole tornare in caso di errore, e
-ripristinandolo, in modo da tornare nella funzione da cui si era partiti,
-quando serve. La funzione che permette di salvare il contesto dello
+ripristinandolo, in modo da tornare quando serve nella funzione da cui si era
+partiti. La funzione che permette di salvare il contesto dello
\itindex{stack} \textit{stack} è \funcd{setjmp}, il cui prototipo è:
-\begin{functions}
- \headdecl{setjmp.h}
- \funcdecl{int setjmp(jmp\_buf env)}
-
- Salva il contesto dello stack.
- \bodydesc{La funzione ritorna zero quando è chiamata direttamente e un
- valore diverso da zero quando ritorna da una chiamata di \func{longjmp}
- che usa il contesto salvato in precedenza.}
-\end{functions}
+\begin{funcproto}{
+\fhead{setjmp.h}
+\fdecl{int setjmp(jmp\_buf env)}
+\fdesc{Salva il contesto dello \textit{stack}.}
+}
+{La funzione ritorna $0$ quando è chiamata direttamente ed un valore diverso
+ da zero quando ritorna da una chiamata di \func{longjmp} che usa il contesto
+ salvato in precedenza.}
+\end{funcproto}
Quando si esegue la funzione il contesto corrente dello \itindex{stack}
\textit{stack} viene salvato nell'argomento \param{env}, una variabile di tipo
\func{longjmp} può comportare conseguenze imprevedibili (e di norma fatali)
per il processo.
-Come accennato per effettuare un salto non-locale ad
-un punto precedentemente stabilito con \func{setjmp} si usa la funzione
-\funcd{longjmp}; il suo prototipo è:
-\begin{functions}
- \headdecl{setjmp.h}
- \funcdecl{void longjmp(jmp\_buf env, int val)}
-
- Ripristina il contesto dello stack.
-
- \bodydesc{La funzione non ritorna.}
-\end{functions}
+Come accennato per effettuare un salto non-locale ad un punto precedentemente
+stabilito con \func{setjmp} si usa la funzione \funcd{longjmp}; il suo
+prototipo è:
+
+\begin{funcproto}{
+\fhead{setjmp.h}
+\fdecl{void longjmp(jmp\_buf env, int val)}
+\fdesc{Ripristina il contesto dello stack.}
+}
+{La funzione non ritorna.}
+\end{funcproto}
La funzione ripristina il contesto dello \itindex{stack} \textit{stack}
salvato da una chiamata a \func{setjmp} nell'argomento \param{env}. Dopo
-l'esecuzione della funzione il programma prosegue nel codice successivo al
-ritorno della \func{setjmp} con cui si era salvato \param{env}, che restituirà
-il valore
-\param{val} invece di zero. Il valore di \param{val} specificato nella
-chiamata deve essere diverso da zero, se si è specificato 0 sarà comunque
-restituito 1 al suo posto.
-
-In sostanza un \func{longjmp} è analogo ad un \code{return}, solo che invece
-di ritornare alla riga successiva della funzione chiamante, il programma
-ritorna alla posizione della relativa \func{setjmp}, l'altra differenza è che
-il ritorno può essere effettuato anche attraverso diversi livelli di funzioni
-annidate.
+l'esecuzione della funzione il programma prosegue nel codice successivo alla
+chiamata della \func{setjmp} con cui si era salvato \param{env}, che
+restituirà il valore dell'argomento \param{val} invece di zero. Il valore
+dell'argomento \param{val} deve essere sempre diverso da zero, se si è
+specificato 0 sarà comunque restituito 1 al suo posto.
+
+In sostanza l'esecuzione di \func{longjmp} è analoga a quella di una
+istruzione \instruction{return}, solo che invece di ritornare alla riga
+successiva della funzione chiamante, il programma in questo caso ritorna alla
+posizione della relativa \func{setjmp}. L'altra differenza fondamentale con
+\instruction{return} è che il ritorno può essere effettuato anche attraverso
+diversi livelli di funzioni annidate.
L'implementazione di queste funzioni comporta alcune restrizioni dato che esse
interagiscono direttamente con la gestione dello \itindex{stack}
\textit{stack} ed il funzionamento del compilatore stesso. In particolare
\func{setjmp} è implementata con una macro, pertanto non si può cercare di
-ottenerne l'indirizzo, ed inoltre delle chiamate a questa funzione sono sicure
+ottenerne l'indirizzo, ed inoltre le chiamate a questa funzione sono sicure
solo in uno dei seguenti casi:
\begin{itemize*}
-\item come espressione di controllo in un comando condizionale, di selezione
- o di iterazione (come \code{if}, \code{switch} o \code{while});
+\item come espressione di controllo in un comando condizionale, di selezione o
+ di iterazione (come \instruction{if}, \instruction{switch} o
+ \instruction{while});
\item come operando per un operatore di uguaglianza o confronto in una
espressione di controllo di un comando condizionale, di selezione o di
iterazione;
In generale, dato che l'unica differenza fra la chiamata diretta e quella
ottenuta nell'uscita con un \func{longjmp} è costituita dal valore di ritorno
-di \func{setjmp}, quest'ultima usualmente viene chiamata all'interno di un
-comando \code{if}.
+di \func{setjmp}, pertanto quest'ultima viene usualmente chiamata all'interno
+di un una istruzione \instruction{if} che permetta di distinguere i due casi.
Uno dei punti critici dei salti non-locali è quello del valore delle
variabili, ed in particolare quello delle \index{variabili!automatiche}
\index{salto~non-locale|)}
-\subsection{La \textit{endianess}}
-\label{sec:sock_endianess}
+\subsection{La \textit{endianness}}
+\label{sec:sock_endianness}
-\itindbeg{endianess}
+\itindbeg{endianness}
-Uno dei problemi di programmazione che può dar luogo ad effetti imprevisti è
-quello relativo alla cosiddetta \textit{endianess}. Questa è una
+Un altro dei problemi di programmazione che può dar luogo ad effetti
+imprevisti è quello relativo alla cosiddetta \textit{endianness}. Questa è una
caratteristica generale dell'architettura hardware di un computer che dipende
dal fatto che la rappresentazione di un numero binario può essere fatta in due
modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
cablati sui bus interni del computer).
\begin{figure}[!htb]
- \centering \includegraphics[height=3cm]{img/endianess}
+ \centering \includegraphics[height=3cm]{img/endianness}
\caption{Schema della disposizione dei dati in memoria a seconda della
- \textit{endianess}.}
- \label{fig:sock_endianess}
+ \textit{endianness}.}
+ \label{fig:sock_endianness}
\end{figure}
Per capire meglio il problema si consideri un intero a 32 bit scritto in una
locazione di memoria posta ad un certo indirizzo. Come illustrato in
-fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
+fig.~\ref{fig:sock_endianness} i singoli bit possono essere disposti in memoria
in due modi: a partire dal più significativo o a partire dal meno
significativo. Così nel primo caso si troverà il byte che contiene i bit più
significativi all'indirizzo menzionato e il byte con i bit meno significativi
parte dal bit meno significativo è detto per lo stesso motivo \textit{little
endian}.
-Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+Si può allora verificare quale tipo di \textit{endianness} usa il proprio
computer con un programma elementare che si limita ad assegnare un valore ad
una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
endian} otterremo qualcosa del tipo:
-\begin{verbatim}
+\begin{Command}
[piccardi@gont sources]$ ./endtest
+\end{Command}
+%$
+\begin{Terminal}
Using value ABCDEF01
val[0]= 1
val[1]=EF
val[2]=CD
val[3]=AB
-\end{verbatim}%$
+\end{Terminal}
mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
qualcosa del tipo:
-\begin{verbatim}
+\begin{Command}
piccardi@anarres:~/gapil/sources$ ./endtest
+\end{Command}
+%$
+\begin{Terminal}
Using value ABCDEF01
val[0]=AB
val[1]=CD
val[2]=EF
val[3]= 1
-\end{verbatim}%$
+\end{Terminal}
-L'attenzione alla \textit{endianess} nella programmazione è importante, perché
+L'attenzione alla \textit{endianness} nella programmazione è importante, perché
se si fanno assunzioni relative alla propria architettura non è detto che
queste restino valide su un'altra architettura. Inoltre, come vedremo ad
esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
si trova a usare valori di un formato con una infrastruttura che ne usa
un altro.
-La \textit{endianess} di un computer dipende essenzialmente dalla architettura
+La \textit{endianness} di un computer dipende essenzialmente dalla architettura
hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
-cosiddetto \textit{network order} è anch'esso \textit{big endian}; altri
+cosiddetto \textit{network order}) è anch'esso \textit{big endian}; altri
esempi di uso di questi due diversi formati sono quello del bus PCI, che è
\textit{little endian}, o quello del bus VME che è \textit{big endian}.
Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianness}, che sia
\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
il valore del confronto delle due variabili.
-\itindend{endianess}
+In generale non ci si deve preoccupare della \textit{endianness} all'interno
+di un programma fintanto che questo non deve generare o manipolare dei dati
+che sono scambiati con altre macchine, ad esempio tramite via rete o tramite
+dei file binari. Nel primo caso la scelta è già stata fatta nella
+standardizzazione dei protocolli, che hanno adottato il \textit{big endian}
+(che viene detto anche per questo \textit{network order} e vedremo in
+sez.~\ref{sec:sock_func_ord} le funzioni di conversione che devono essere
+usate.
+
+Nel secondo caso occorre sapere quale \textit{endianness} è stata usata nei
+dati memorizzati sul file e tenerne conto nella rilettura e nella
+manipolazione e relativa modifica (e salvataggio). La gran parte dei formati
+binari standardizzati specificano quale \textit{endianness} viene utilizzata e
+basterà identificare qual'è, se se ne deve definire uno per i propri scopi
+basterà scegliere una volta per tutte quale usare e attenersi alla scelta.
+
+\itindend{endianness}
% LocalWords: like exec kernel thread main ld linux static linker char envp Gb
% LocalWords: exithandler handler violation inline SOURCE SVID XOPEN mincore
% LocalWords: length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
% LocalWords: boundary memptr alignment sizeof overrun mcheck abortfn enum big
-% LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianess IBM
+% LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianness IBM
% LocalWords: endian little endtest Macintosh PowerPC Intel Digital Motorola
% LocalWords: Sun order VME loader Windows DLL shared objects PRELOAD termios
% LocalWords: is to LC SIG str mem wcs assert ctype dirent fcntl signal stdio
% LocalWords: times library utmp syscall number Filesystem Hierarchy pathname
% LocalWords: context assembler sysconf fork Dinamic huge segmentation program
-% LocalWords: break store
+% LocalWords: break store Using
%%% Local Variables:
%%% mode: latex
\chapter{La gestione dei processi}
\label{cha:process_handling}
-Come accennato nell'introduzione in un sistema Unix tutte le operazioni
+Come accennato nell'introduzione in un sistema unix-like tutte le operazioni
vengono svolte tramite opportuni processi. In sostanza questi ultimi vengono
a costituire l'unità base per l'allocazione e l'uso delle risorse del sistema.
ambiente multitasking.
-\section{Introduzione}
-\label{sec:proc_gen}
+\section{Le funzioni di base}% della gestione dei processi}
+\label{sec:proc_handling}
-Inizieremo con un'introduzione generale ai concetti che stanno alla base della
-gestione dei processi in un sistema unix-like. Introdurremo in questa sezione
-l'architettura della gestione dei processi e le sue principali
-caratteristiche, dando una panoramica sull'uso delle principali funzioni di
-gestione.
+In questa sezione tratteremo le problematiche della gestione dei processi
+all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con una
+panoramica dell'architettura dei processi, tratteremo poi le funzioni
+elementari che permettono di leggerne gli identificatori, per poi passare alla
+spiegazione delle funzioni base che si usano per la creazione e la
+terminazione dei processi, e per la messa in esecuzione degli altri programmi.
\subsection{L'architettura della gestione dei processi}
\label{sec:proc_hierarchy}
-A differenza di quanto avviene in altri sistemi (ad esempio nel VMS la
-generazione di nuovi processi è un'operazione privilegiata) una delle
-caratteristiche di Unix (che esamineremo in dettaglio più avanti) è che
-qualunque processo può a sua volta generarne altri, detti processi figli
-(\textit{child process}). Ogni processo è identificato presso il sistema da un
-numero univoco, il cosiddetto \textit{process identifier} o, più brevemente,
-\acr{pid}, assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid})
-quando il processo viene creato.
+A differenza di quanto avviene in altri sistemi, ad esempio nel VMS 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 identifier} o, più brevemente, \acr{pid}, assegnato in forma
+progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
-Una seconda caratteristica di un sistema Unix è che la generazione di un
+Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
genere la sequenza è sempre quella di creare un nuovo processo, il quale
eseguirà, in un passo successivo, il programma desiderato: questo è ad esempio
quello che fa la shell quando mette in esecuzione il programma che gli
indichiamo nella linea di comando.
-Una terza caratteristica è che ogni processo è sempre stato generato da un
-altro, che viene chiamato 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 viene lanciato dal kernel alla conclusione della fase
-di avvio; essendo questo il primo processo lanciato dal sistema ha sempre il
-\acr{pid} uguale a 1 e non è figlio di nessun altro processo.
+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 \acr{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,
struttura del sistema comunque consente di lanciare al posto di \cmd{init}
qualunque altro programma, e in casi di emergenza (ad esempio se il file di
\cmd{init} si fosse corrotto) è ad esempio possibile lanciare una shell al suo
-posto, passando la riga \cmd{init=/bin/sh} come parametro di avvio.
+posto.\footnote{la cosa si fa passando la riga \cmd{init=/bin/sh} come
+ parametro di avvio del kernel, l'argomento è di natura amministrativa e
+ trattato in sez.~5.3 di \cite{AGL}.}
\begin{figure}[!htb]
\footnotesize
-\begin{verbatim}
+\begin{Command}
[piccardi@gont piccardi]$ pstree -n
+\end{Command}
+\begin{Terminal}
init-+-keventd
|-kapm-idled
|-kreiserfsd
|-5*[getty]
|-snort
`-wwwoffled
-\end{verbatim} %$
+\end{Terminal}
+%$
\caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
\label{fig:proc_tree}
\end{figure}
Dato che tutti i processi attivi nel sistema sono comunque generati da
-\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}, 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
-sez.~\ref{sec:file_organization}); in fig.~\ref{fig:proc_tree} si è mostrato il
-risultato del comando \cmd{pstree} che permette di visualizzare questa
-struttura, alla cui base c'è \cmd{init} che è progenitore di tutti gli altri
-processi.
+\cmd{init} o da uno dei suoi figli si possono classificare i processi con la
+relazione padre/figlio in un'organizzazione gerarchica ad albero. In
+fig.~\ref{fig:proc_tree} si è mostrato il risultato del comando \cmd{pstree}
+che permette di visualizzare questa struttura, alla cui base c'è \cmd{init}
+che è progenitore di tutti gli altri processi.\footnote{in realtà questo non è
+ del tutto vero, in Linux, specialmente nelle versioni più recenti del
+ kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd},
+ ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con
+ \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che
+ non rientrano in questa classificazione.}
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
-\itindex{process~table} \textit{process table}; per ciascun processo viene
-mantenuta una voce, costituita da una struttura \struct{task\_struct}, nella
-tabella dei processi che contiene tutte le informazioni rilevanti per quel
-processo. Tutte le strutture usate a questo scopo sono dichiarate nell'header
-file \file{linux/sched.h}, ed uno schema semplificato, che riporta la
-struttura delle principali informazioni contenute nella \struct{task\_struct}
-(che in seguito incontreremo a più riprese), è mostrato in
-fig.~\ref{fig:proc_task_struct}.
+\itindex{process~table} \textit{process table}. Per ciascun processo viene
+mantenuta una voce in questa tabella, costituita da una struttura
+\struct{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
+\struct{task\_struct} (che in seguito incontreremo a più riprese), è mostrato
+in fig.~\ref{fig:proc_task_struct}.
\begin{figure}[!htb]
\centering \includegraphics[width=14cm]{img/task_struct}
Come accennato in sez.~\ref{sec:intro_unix_struct} è lo \itindex{scheduler}
\textit{scheduler} che decide quale processo mettere in esecuzione; esso viene
-eseguito ad ogni system call ed ad ogni interrupt,\footnote{più in una serie
- di altre occasioni.} ma può essere anche attivato esplicitamente. Il timer
-di sistema provvede comunque a che esso sia invocato periodicamente; generando
-un interrupt periodico secondo la frequenza specificata dalla costante
+eseguito ad ogni \textit{system call} ed ad ogni interrupt e in una serie di
+altre occasioni, ma può essere anche attivato esplicitamente. Il timer di
+sistema provvede comunque a che esso sia invocato periodicamente; generando un
+interrupt periodico secondo la frequenza specificata dalla costante
\const{HZ},\footnote{fino al kernel 2.4 il valore di \const{HZ} era 100 su
tutte le architetture tranne l'alpha, per cui era 1000, nel 2.6 è stato
portato a 1000 su tutte; dal 2.6.13 lo si può impostare in fase di
refresh della televisione); occorre fare attenzione a non confondere questo
valore con quello dei \itindex{clock~tick} \textit{clock tick} (vedi
sez.~\ref{sec:sys_unix_time}).} definita in \file{asm/param.h}, ed il cui
-valore è espresso in Hertz.\footnote{a partire dal kernel 2.6.21 è stato
- introdotto (a cura di Ingo Molnar) un meccanismo completamente diverso,
- detto \textit{tickless}, in cui non c'è più una interruzione periodica con
- frequenza prefissata, ma ad ogni chiamata del timer viene programmata
- l'interruzione successiva sulla base di una stima; in questo modo si evita
- di dover eseguire un migliaio di interruzioni al secondo anche su macchine
- che non stanno facendo nulla, con un forte risparmio nell'uso dell'energia
- da parte del processore che può essere messo in stato di sospensione anche
- per lunghi periodi di tempo.}
-
-Ogni volta che viene eseguito, lo \itindex{scheduler} \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 invocazione.
-
-
-\subsection{Una panoramica sulle funzioni fondamentali}
-\label{sec:proc_handling_intro}
-
-Tradizionalmente in un sistema unix-like i processi vengono sempre creati da
-altri processi tramite la funzione \func{fork}; il nuovo processo (che viene
-chiamato \textsl{figlio}) creato dalla \func{fork} è una copia identica del
-processo processo originale (detto \textsl{padre}), ma ha un nuovo \acr{pid} e
-viene eseguito in maniera indipendente (le differenze fra padre e figlio sono
-affrontate in dettaglio in sez.~\ref{sec:proc_fork}).
-
-Se si vuole che il processo padre si fermi fino alla conclusione del processo
-figlio questo deve essere specificato subito dopo la \func{fork} chiamando la
-funzione \func{wait} o la funzione \func{waitpid} (si veda
-sez.~\ref{sec:proc_wait}); queste funzioni restituiscono anche un'informazione
-abbastanza limitata sulle cause della terminazione del processo figlio.
-
-Quando un processo ha concluso il suo compito o ha incontrato un errore non
-risolvibile esso può essere terminato con la funzione \func{exit} (si veda
-quanto discusso in sez.~\ref{sec:proc_conclusion}). La vita del processo però
-termina completamente solo quando la notifica della sua conclusione viene
-ricevuta dal processo padre, a quel punto tutte le risorse allocate nel
-sistema ad esso associate vengono rilasciate.
-
-Avere due processi che eseguono esattamente lo stesso codice non è molto
-utile, normalmente si genera un secondo processo per affidargli l'esecuzione
-di un compito specifico (ad esempio gestire una connessione dopo che questa è
-stata stabilita), o fargli eseguire (come fa la shell) un altro programma. Per
-quest'ultimo caso si usa la seconda funzione fondamentale per programmazione
-coi processi che è la \func{exec}.
-
-Il programma che un processo sta eseguendo si chiama immagine del processo (o
-\textit{process image}), le funzioni della famiglia \func{exec} permettono di
-caricare un altro programma da disco sostituendo quest'ultimo all'immagine
-corrente; questo fa sì che l'immagine precedente venga completamente
-cancellata. Questo significa che quando il nuovo programma termina, anche il
-processo termina, e non si può tornare alla precedente immagine.
-
-Per questo motivo la \func{fork} e la \func{exec} sono funzioni molto
-particolari con caratteristiche uniche rispetto a tutte le altre, infatti la
-prima ritorna due volte (nel processo padre e nel figlio) mentre la seconda
-non ritorna mai (in quanto con essa viene eseguito un altro programma).
-
+valore è espresso in Hertz.
-\section{Le funzioni di base}% della gestione dei processi}
-\label{sec:proc_handling}
+A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
+completamente diverso, detto \textit{tickless}, in cui non c'è più una
+interruzione periodica con frequenza prefissata, ma ad ogni chiamata del timer
+viene programmata l'interruzione successiva sulla base di una stima; in questo
+modo si evita di dover eseguire un migliaio di interruzioni al secondo anche
+su macchine che non stanno facendo nulla, con un forte risparmio nell'uso
+dell'energia da parte del processore che può essere messo in stato di
+sospensione anche per lunghi periodi di tempo.
-In questa sezione tratteremo le problematiche della gestione dei processi
-all'interno del sistema, illustrandone tutti i dettagli. Inizieremo con le
-funzioni elementari che permettono di leggerne gli identificatori, per poi
-passare alla spiegazione delle funzioni base che si usano per la creazione e
-la terminazione dei processi, e per la messa in esecuzione degli altri
-programmi.
+Indipendentemente dalle motivazioni per cui questo avviene, ogni volta che
+viene eseguito lo \itindex{scheduler} \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 invocazione.
\subsection{Gli identificatori dei processi}
\label{sec:proc_pid}
-Come accennato nell'introduzione, ogni processo viene identificato dal sistema
-da un numero identificativo univoco, il \textit{process ID} o \acr{pid};
-quest'ultimo è un tipo di dato standard, il \type{pid\_t} che in genere è un
+Come accennato nella sezione precedente ogni processo viene identificato dal
+sistema da un numero identificativo univoco, il \textit{process ID} o
+\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è
\ctyp{int}).
-Il \acr{pid} viene assegnato in forma progressiva\footnote{in genere viene
- assegnato il numero successivo a quello usato per l'ultimo processo creato,
- a meno che questo numero non sia già utilizzato per un altro \acr{pid},
- \acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} ogni volta
-che un nuovo processo viene creato, fino ad un limite che, essendo il
-\acr{pid} un numero positivo memorizzato in un intero a 16 bit, arriva ad un
-massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più
-basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino
- al kernel 2.4.x, sono definiti dalla macro \const{PID\_MAX} in
- \file{threads.h} e direttamente in \file{fork.c}, con il kernel 2.5.x e la
- nuova interfaccia per i \itindex{thread} \textit{thread} creata da Ingo
- Molnar anche il meccanismo di allocazione dei \acr{pid} è stato modificato;
- il valore massimo è impostabile attraverso il file
+Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo
+processo viene creato,\footnote{in genere viene assegnato il numero successivo
+ a quello usato per l'ultimo processo creato, a meno che questo numero non
+ sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi
+ sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il
+tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16
+bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione
+riparte dal numero più basso disponibile a partire da un minimo di
+300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro
+ \const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del
+ kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread}
+ \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato
+ modificato ed il valore massimo è impostabile attraverso il file
\procfile{/proc/sys/kernel/pid\_max} e di default vale 32768.} che serve a
riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel.
Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
\textit{parent process ID}). Questi due identificativi possono essere
ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui
prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
- \funcdecl{pid\_t getpid(void)}
-
- Restituisce il \acr{pid} del processo corrente.
-
- \funcdecl{pid\_t getppid(void)}
-
- Restituisce il \acr{pid} del padre del processo corrente.
-\bodydesc{Entrambe le funzioni non riportano condizioni di errore.}
-\end{functions}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{unistd.h}
+\fdecl{pid\_t getpid(void)}
+\fdesc{Restituisce il \acr{pid} del processo corrente..}
+\fdecl{pid\_t getppid(void)}
+\fdesc{Restituisce il \acr{pid} del padre del processo corrente.}
+}
+{Entrambe le funzioni non riportano condizioni di errore.}
+\end{funcproto}
+
\noindent esempi dell'uso di queste funzioni sono riportati in
fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}.
diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la
funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il
\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che
-non potrà essere replicato da un altro processo che usi la stessa funzione.
+non potrà essere replicato da un altro processo che usi la stessa
+funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti
+è univoco solo fintanto che un processo è attivo, una volta terminato esso
+potrà essere riutilizzato da un processo completamente diverso, e di questo
+bisogna essere ben consapevoli.
Tutti i processi figli dello stesso processo padre sono detti
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
-Oltre al \acr{pid} e al \acr{ppid}, (e a quelli che vedremo in
-sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione), ad ogni
-processo vengono associati degli altri identificatori che vengono usati per il
-controllo di accesso. Questi servono per determinare se un processo può
-eseguire o meno le operazioni richieste, a seconda dei privilegi e
-dell'identità di chi lo ha posto in esecuzione; l'argomento è complesso e sarà
-affrontato in dettaglio in sez.~\ref{sec:proc_perms}.
+Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in
+sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni
+processo vengono associati degli ulteriori identificatori ed in particolare
+quelli che vengono usati per il controllo di accesso. Questi servono per
+determinare se un processo può eseguire o meno le operazioni richieste, a
+seconda dei privilegi e dell'identità di chi lo ha posto in esecuzione;
+l'argomento è complesso e sarà affrontato in dettaglio in
+sez.~\ref{sec:proc_perms}.
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\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 è:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{unistd.h}
- \funcdecl{pid\_t fork(void)}
- Crea un nuovo processo.
-
- \bodydesc{In caso di successo restituisce il \acr{pid} del figlio al padre e
- zero al figlio; ritorna -1 al padre (senza creare il figlio) in caso di
- errore; \var{errno} può assumere i valori:
+
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{pid\_t fork(void)}
+\fdesc{Crea un nuovo processo.}
+}
+{La funzione ritorna il \acr{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:
\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
\item[\errcode{ENOMEM}] non è stato possibile allocare la memoria per le
strutture necessarie al kernel per creare il nuovo processo.
\end{errlist}}
-\end{functions}
+\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
-dall'istruzione successiva alla \func{fork}; il processo figlio è però una
-copia del padre, e riceve una copia dei \index{segmento!testo} segmenti di
-testo, \itindex{stack} \textit{stack} e \index{segmento!dati} dati (vedi
+dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia del
+padre, e riceve una copia dei \index{segmento!testo} segmenti di testo,
+\index{segmento!dati} dati e dello \itindex{stack} \textit{stack} (vedi
sez.~\ref{sec:proc_mem_layout}), ed esegue esattamente lo stesso codice del
-padre. Si tenga presente però che la memoria è copiata, non condivisa,
-pertanto padre e figlio vedono variabili diverse.
+padre. Si tenga presente però che la memoria è copiata e non condivisa,
+pertanto padre e figlio vedranno variabili diverse e le eventuali modifiche
+saranno totalmente indipendenti.
Per quanto riguarda la gestione della memoria, in generale il
\index{segmento!testo} segmento di testo, che è identico per i due processi, è
-condiviso e tenuto in read-only per il padre e per i figli. Per gli altri
+condiviso e tenuto in sola lettura per il padre e per i figli. Per gli altri
segmenti Linux utilizza la tecnica del \itindex{copy~on~write} \textit{copy on
- write}; questa tecnica comporta che una pagina di memoria viene
+ write}. Questa tecnica comporta che una pagina di memoria viene
effettivamente copiata per il nuovo processo solo quando ci viene effettuata
-sopra una scrittura (e si ha quindi una reale differenza fra padre e figlio).
+sopra una scrittura, e si ha quindi una reale differenza fra padre e figlio.
In questo modo si rende molto più efficiente il meccanismo della creazione di
un nuovo processo, non essendo più necessaria la copia di tutto lo spazio
degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono
ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre
nel figlio è zero; in questo modo il programma può identificare se viene
eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni
-\textbf{due} volte: una nel padre e una nel figlio.
+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 \acr{pid} può sempre essere ottenuto con
-\func{getppid}, vedi sez.~\ref{sec:proc_pid}) per cui si usa il valore nullo,
-che non è il \acr{pid} di nessun processo.
-
-\begin{figure}[!htbp]
- \footnotesize \centering
- \begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/ForkTest.c}
- \end{minipage}
- \normalsize
- \caption{Esempio di codice per la creazione di nuovi processi.}
- \label{fig:proc_fork_code}
-\end{figure}
-
-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
-qualcos'altro non sta andando per il verso giusto) o si è ecceduto il limite
-sul numero totale di processi permessi all'utente (vedi
-sez.~\ref{sec:sys_resource_limit}, ed in particolare
+permette di identificare quello appena creato. Al contrario un figlio ha
+sempre un solo padre, il cui \acr{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 \acr{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
+qualcos'altro non sta andando per il verso giusto, o si è ecceduto il limite
+sul numero totale di processi permessi all'utente argomento su cui torneremo
+in sez.~\ref{sec:sys_resource_limit}, (vedi in particolare
tab.~\ref{tab:sys_rlimit_values}).
L'uso di \func{fork} avviene secondo due modalità principali; la prima è
operazione che viene chiamata \textit{spawn}. Nei sistemi unix-like è stato
scelto di mantenere questa separazione, dato che, come per la prima modalità
d'uso, esistono numerosi scenari in cui si può usare una \func{fork} senza
-aver bisogno di eseguire una \func{exec}. Inoltre, anche nel caso della
-seconda modalità d'uso, avere le due funzioni separate permette al figlio di
-cambiare gli attributi del processo (maschera dei segnali, redirezione
-dell'output, identificatori) prima della \func{exec}, rendendo così
-relativamente facile intervenire sulle le modalità di esecuzione del nuovo
-programma.
+aver bisogno di eseguire una \func{exec}.
+
+Inoltre, anche nel caso della seconda modalità d'uso, avere le due funzioni
+separate permette al figlio di cambiare alcune caratteristiche del processo
+(maschera dei segnali, redirezione dell'output, utente per conto del cui viene
+eseguito, e molto altro su cui torneremo in seguito) prima della \func{exec},
+rendendo così relativamente facile intervenire sulle le modalità di esecuzione
+del nuovo programma.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/ForkTest.c}
+ \end{minipage}
+ \normalsize
+ \caption{Esempio di codice per la creazione di nuovi processi.}
+ \label{fig:proc_fork_code}
+\end{figure}
In fig.~\ref{fig:proc_fork_code} è riportato il corpo del codice del programma
di esempio \cmd{forktest}, che permette di illustrare molte caratteristiche
specificato da linea di comando, e prende anche alcune opzioni per indicare
degli eventuali tempi di attesa in secondi (eseguiti tramite la funzione
\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
+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.truelite.it/gapil_source.tgz}
-{\textsf{http://gapil.truelite.it/gapil\_source.tgz}}.
+\url{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
alla conclusione del ciclo, prima di uscire, può essere specificato un altro
periodo di attesa.
-Se eseguiamo il comando\footnote{che è preceduto dall'istruzione \code{export
- LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche.}
-senza specificare attese (come si può notare in (\texttt{\small 17--19}) i
-valori predefiniti specificano di non attendere), otterremo come output sul
+Se eseguiamo il comando, che è preceduto dall'istruzione \code{export
+ LD\_LIBRARY\_PATH=./} per permettere l'uso delle librerie dinamiche, senza
+specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
+predefiniti specificano di non attendere), otterremo come risultato sul
terminale:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
+\end{Command}
+%$
+\begin{Terminal}
Process 1963: forking 3 child
Spawned 1 child, pid 1964
Child 1 successfully executing
Child 3, parent 1963, exiting
Spawned 3 child, pid 1966
Go to next child
-\end{Verbatim}
-%$
+\end{Terminal}
Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
si può dire quale processo fra il padre ed il figlio venga eseguito per primo
rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
condition} (vedi sez.~\ref{sec:proc_race_cond}).
-In realtà a partire dal kernel 2.5.2-pre10 il nuovo \itindex{scheduler}
-\textit{scheduler} di Ingo Molnar esegue sempre per primo il
-figlio;\footnote{i risultati precedenti sono stati ottenuti usando un kernel
- della serie 2.4.} questa è una ottimizzazione che serve a evitare che il
-padre, effettuando per primo una operazione di scrittura in memoria, attivi il
-meccanismo del \itindex{copy~on~write} \textit{copy on write}. Questa
-operazione infatti potrebbe risultare del tutto inutile qualora il figlio
-fosse stato creato solo per eseguire una \func{exec}, in tal caso infatti si
-invocherebbe un altro programma scartando completamente lo spazio degli
-indirizzi, rendendo superflua la copia della memoria modificata dal padre.
-
-% TODO spiegare l'ulteriore cambiamento in ponte con il 2.6.32, che fa girare
-% prima il padre per questioni di caching nella CPU
-
-Eseguendo sempre per primo il figlio la \func{exec} verrebbe effettuata subito
-avendo così la certezza che il \itindex{copy~on~write} \textit{copy on write}
-viene utilizzato solo quando necessario. Quanto detto in precedenza vale
-allora soltanto per i kernel fino al 2.4; per mantenere la portabilità è però
-opportuno non fare affidamento su questo comportamento, che non si riscontra
-in altri Unix e nelle versioni del kernel precedenti a quella indicata.
-
-Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli
-processi completamente separati, 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).
+In realtà con l'introduzione dei kernel della serie 2.6 lo \itindex{scheduler}
+\textit{scheduler} è stato modificato per eseguire sempre per primo il
+figlio.\footnote{i 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 \itindex{copy~on~write} \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 \itindex{copy~on~write} \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
+vantaggio di poter utilizzare immediatamente tutti i dati che sono nella cache
+della CPU e nella 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.
Un secondo aspetto molto importante nella creazione dei processi figli è
-quello dell'interazione dei vari processi con i file; per illustrarlo meglio
-proviamo a redirigere su un file l'output del nostro programma di test, quello
-che otterremo è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+quello dell'interazione dei vari processi con i file. Ne parleremo qui anche
+se buona parte dei concetti relativi ai file verranno trattati più avanti
+(principalmente nel cap.~\ref{cha:file_unix_interface}). Per illustrare meglio
+quello che avviene si può redirigere su un file l'output del programma di
+test, quello che otterremo è:
+\begin{Command}
[piccardi@selidor sources]$ ./forktest 3 > output
[piccardi@selidor sources]$ cat output
+\end{Command}
+\begin{Terminal}
Process 1967: forking 3 child
Child 1 successfully executing
Child 1, parent 1967, exiting
Go to next child
Spawned 3 child, pid 1970
Go to next child
-\end{Verbatim}
+\end{Terminal}
che come si vede è completamente diverso da quanto ottenevamo sul terminale.
Il comportamento delle varie funzioni di interfaccia con i file è analizzato
-in gran dettaglio in cap.~\ref{cha:file_unix_interface} e in
-cap.~\ref{cha:files_std_interface}. Qui basta accennare che si sono usate le
-funzioni standard della libreria del C che prevedono l'output bufferizzato; e
-questa bufferizzazione (trattata 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 (nel qual caso il
-buffer viene scaricato ad ogni carattere di a capo).
-
-Nel primo esempio allora avevamo che ad ogni chiamata a \func{printf} il
-buffer veniva scaricato, e le singole righe erano stampate a video subito dopo
-l'esecuzione della \func{printf}. Ma con la redirezione su file la scrittura
-non avviene più alla fine di ogni riga e l'output resta nel buffer. Dato che
-ogni figlio riceve una copia della memoria del padre, esso riceverà anche
-quanto c'è nel buffer delle funzioni di I/O, comprese le linee scritte dal
-padre fino allora. Così quando il buffer viene scritto su disco all'uscita del
-figlio, troveremo nel file anche tutto quello che il processo padre aveva
-scritto prima della sua creazione. E alla fine del file (dato che in questo
-caso il padre esce per ultimo) troveremo anche l'output completo del padre.
+in gran dettaglio in cap.~\ref{cha:file_unix_interface} per l'interfaccia
+nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione
+adottata nelle librerie del linguaggio C e 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.
+
+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
+le singole righe comparivano a video subito dopo l'esecuzione della
+\func{printf}. Ma con la redirezione su file la scrittura non avviene più alla
+fine di ogni riga e l'output resta nel buffer. Dato che ogni figlio riceve una
+copia della memoria del padre, esso riceverà anche quanto c'è nel buffer delle
+funzioni di I/O, comprese le linee scritte dal padre fino allora. Così quando
+il buffer viene scritto su disco all'uscita del figlio, troveremo nel file
+anche tutto quello che il processo padre aveva scritto prima della sua
+creazione. E alla fine del file (dato che in questo caso il padre esce per
+ultimo) troveremo anche l'output completo del padre.
L'esempio ci mostra un altro aspetto fondamentale dell'interazione con i file,
valido anche per l'esempio precedente, ma meno evidente: il fatto cioè che non
solo processi diversi possono scrivere in contemporanea sullo stesso file
(l'argomento della condivisione dei file è trattato in dettaglio in
sez.~\ref{sec:file_sharing}), ma anche che, a differenza di quanto avviene per
-le variabili, la posizione corrente sul file è condivisa fra il padre e tutti
-i processi figli.
-
-Quello che succede è che quando lo standard output del padre viene rediretto
-come si è fatto nell'esempio, lo stesso avviene anche per tutti i figli; la
-funzione \func{fork} infatti ha la caratteristica di duplicare nei processi
-figli tutti i file descriptor 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
-\itindex{file~table} \textit{file table} (per la spiegazione di questi termini
-si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente
-nel file.
-
-In questo modo se un processo scrive sul file aggiornerà la posizione corrente
-sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
-che vedono la stessa \itindex{file~table} \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.
+le variabili in memoria, la posizione corrente sul file è condivisa fra il
+padre e tutti i processi figli.
+
+Quello che succede è che quando lo \textit{standard output}\footnote{si chiama
+ così il file su cui un programma scrive i suoi dati in uscita, tratteremo
+ l'argomento in dettaglio in sez.~\ref{sec:file_std_descr}.} del padre viene
+rediretto come si è fatto nell'esempio, lo stesso avviene anche per tutti i
+figli. La funzione \func{fork} infatti ha la caratteristica di duplicare nei
+processi figli tutti i 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 \itindex{file~table} \textit{file
+ table} (tratteremo in dettagli questi termini in
+sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file.
+
+In questo modo se un processo scrive su un file aggiornerà la posizione
+corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
+processi, che vedono la stessa \itindex{file~table} \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.
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
-scrivono sullo stesso file; un caso tipico è la shell quando lancia un
-programma, il cui output va sullo standard output. In questo modo, anche se
-l'output viene rediretto, il padre potrà sempre continuare a scrivere in coda
-a quanto scritto dal figlio in maniera automatica; se così non fosse ottenere
-questo comportamento sarebbe estremamente complesso necessitando di una
-qualche forma di comunicazione fra i due processi per far riprendere al padre
-la scrittura al punto giusto.
+scrivono sullo stesso file. Un caso tipico di questo comportamento è la shell
+quando lancia un programma. In questo modo, anche se lo standard output viene
+rediretto, il padre potrà sempre continuare a scrivere in coda a quanto
+scritto dal figlio in maniera automatica; se così non fosse ottenere questo
+comportamento sarebbe estremamente complesso necessitando di una qualche forma
+di comunicazione fra i due processi per far riprendere al padre la scrittura
+al punto giusto.
In generale comunque non è buona norma far scrivere più processi sullo stesso
file senza una qualche forma di sincronizzazione in quanto, come visto anche
processore (vedi sez.~\ref{sec:proc_sched_stand},
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
+\item l'insieme dei descrittori associati alle code di messaggi POSIX (vedi
+ sez.~\ref{sec:ipc_posix_mq}) che vengono copiate come i file descriptor,
+ questo significa che entrambi condivideranno gli stessi flag.
\end{itemize*}
-Le differenze fra padre e figlio dopo la \func{fork} invece sono:\footnote{a
- parte le ultime quattro, relative a funzionalità specifiche di Linux, le
- altre sono esplicitamente menzionate dallo standard POSIX.1-2001.}
+
+Oltre a quelle relative ad un diverso spazio degli indirizzi (e una memoria
+totalmente indipendente) le differenze fra padre e figlio dopo l'esecuzione di
+una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a
+ funzionalità specifiche di Linux, le altre sono esplicitamente menzionate
+ dallo standard POSIX.1-2001.}
\begin{itemize*}
\item il valore di ritorno di \func{fork};
-\item il \acr{pid} (\textit{process id}), assegnato ad un nuovo valore univoco;
+\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad
+ un nuovo valore univoco;
\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
impostato al \acr{pid} del padre;
\item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e
\item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
- notifica al figlio la terminazione del padre viene cancellata;
+ notifica al figlio la terminazione del padre viene cancellata se presente
+ nel padre;
\item il segnale di terminazione del figlio è sempre \signal{SIGCHLD} anche
qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
\end{itemize*}
\label{sec:proc_termination}
In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
-chiudere un programma, ma dall'interno del programma stesso; avendo a che fare
-con un sistema multitasking resta da affrontare l'argomento dal punto di vista
-di come il sistema gestisce la conclusione dei processi.
+chiudere un programma, ma dall'interno del programma stesso. Avendo a che fare
+con un sistema \textit{multitasking} resta da affrontare l'argomento dal punto
+di vista di come il sistema gestisce la conclusione dei processi.
Abbiamo visto in sez.~\ref{sec:proc_conclusion} le tre modalità con cui un
-programma viene terminato in maniera normale: la chiamata di \func{exit} (che
-esegue le funzioni registrate per l'uscita e chiude gli stream), il ritorno
-dalla funzione \func{main} (equivalente alla chiamata di \func{exit}), e la
-chiamata ad \func{\_exit} (che passa direttamente alle operazioni di
-terminazione del processo da parte del kernel).
+programma viene terminato in maniera normale: la chiamata di \func{exit}, che
+esegue le funzioni registrate per l'uscita e chiude i \textit{file stream} e
+poi esegue \func{\_exit}, il ritorno dalla funzione \func{main} equivalente
+alla chiamata di \func{exit}, e la chiamata diretta a \func{\_exit}, che passa
+direttamente alle operazioni di terminazione del processo da parte del kernel.
Ma abbiamo accennato che oltre alla conclusione normale esistono anche delle
-modalità di conclusione anomala; queste sono in sostanza due: il programma può
-chiamare la funzione \func{abort} per invocare una chiusura anomala, o essere
-terminato da un segnale (torneremo sui segnali in cap.~\ref{cha:signals}). In
-realtà anche la prima modalità si riconduce alla seconda, dato che
-\func{abort} si limita a generare il segnale \signal{SIGABRT}.
+modalità di conclusione anomala. Queste sono in sostanza due: il programma può
+chiamare la funzione \func{abort} (vedi sez.~\ref{sec:sig_alarm_abort}) per
+invocare una chiusura anomala, o essere terminato da un segnale (torneremo sui
+segnali in cap.~\ref{cha:signals}). In realtà anche la prima modalità si
+riconduce alla seconda, dato che \func{abort} si limita a generare il segnale
+\signal{SIGABRT}.
Qualunque sia la modalità di conclusione di un processo, il kernel esegue
-comunque una serie di operazioni: chiude tutti i file aperti, rilascia la
-memoria che stava usando, e così via; l'elenco completo delle operazioni
-eseguite alla chiusura di un processo è il seguente:
+comunque una serie di operazioni di terminazione: chiude tutti i file aperti,
+rilascia la memoria che stava usando, e così via; l'elenco completo delle
+operazioni eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
\item tutti i file descriptor sono chiusi;
\item viene memorizzato lo stato di terminazione del processo;
(vedi ancora sez.~\ref{sec:sess_ctrl_term}).
\end{itemize*}
+\itindbeg{termination~status}
+
Oltre queste operazioni è però necessario poter disporre di un meccanismo
ulteriore che consenta di sapere come la terminazione è avvenuta: dato che in
un sistema unix-like tutto viene gestito attraverso i processi, il meccanismo
-scelto consiste nel riportare lo stato di terminazione (il cosiddetto
-\textit{termination status}) al processo padre.
+scelto consiste nel riportare lo \itindex{termination~status} \textsl{stato di
+ terminazione} (il cosiddetto \textit{termination status}) al processo padre.
Nel caso di conclusione normale, abbiamo visto in
sez.~\ref{sec:proc_conclusion} che lo stato di uscita del processo viene
caratterizzato tramite il valore del cosiddetto \textit{exit status}, cioè il
-valore passato alle funzioni \func{exit} o \func{\_exit} (o dal valore di
-ritorno per \func{main}). Ma se il processo viene concluso in maniera anomala
-il programma non può specificare nessun \textit{exit status}, ed è il kernel
-che deve generare autonomamente il \textit{termination status} per indicare le
-ragioni della conclusione anomala.
+valore passato come argomento alle funzioni \func{exit} o \func{\_exit} o il
+valore di ritorno per \func{main}. Ma se il processo viene concluso in
+maniera anomala il programma non può specificare nessun \textit{exit status},
+ed è il kernel che deve generare autonomamente il \textit{termination status}
+per indicare le ragioni della conclusione anomala.
Si noti la distinzione fra \textit{exit status} e \textit{termination status}:
quello che contraddistingue lo stato di chiusura del processo e viene
riportato attraverso le funzioni \func{wait} o \func{waitpid} (vedi
-sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione normale
-il kernel usa il primo (nel codice eseguito da \func{\_exit}) per produrre il
-secondo.
+sez.~\ref{sec:proc_wait}) è sempre quest'ultimo; in caso di conclusione
+normale il kernel usa il primo (nel codice eseguito da \func{\_exit}) per
+produrre il secondo.
La scelta di riportare al padre lo stato di terminazione dei figli, pur
essendo l'unica possibile, comporta comunque alcune complicazioni: infatti se
-alla sua creazione è scontato che ogni nuovo processo ha un padre, non è detto
-che sia così alla sua conclusione, dato che il padre potrebbe essere già
+alla sua creazione è scontato che ogni nuovo processo abbia un padre, non è
+detto che sia così alla sua conclusione, dato che il padre potrebbe essere già
terminato; si potrebbe avere cioè quello che si chiama un processo
-\textsl{orfano}.
+\textsl{orfano}.
Questa complicazione viene superata facendo in modo che il processo orfano
-venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo
-termina, il kernel controlla se è il padre di altri processi in esecuzione: in
-caso positivo allora il \acr{ppid} di tutti questi processi viene sostituito
-con il \acr{pid} di \cmd{init} (e cioè con 1); in questo modo ogni processo
-avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo})
-cui riportare il suo stato di terminazione. Come verifica di questo
-comportamento possiamo eseguire il nostro programma \cmd{forktest} imponendo a
-ciascun processo figlio due secondi di attesa prima di uscire, il risultato è:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1,
+cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base
+dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche
+per questo motivo ha un ruolo essenziale nel sistema e non può mai
+terminare.\footnote{almeno non senza un blocco completo del sistema, in caso
+ di terminazione o di non esecuzione di \cmd{init} infatti il kernel si
+ blocca con un cosiddetto \textit{kernel panic}, dato che questo è un errore
+ fatale.}
+
+Come già accennato quando un processo termina, il kernel controlla se è il
+padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid}
+di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di
+\cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel
+caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo
+stato di terminazione.
+
+Come verifica di questo comportamento possiamo eseguire il nostro programma
+\cmd{forktest} imponendo a ciascun processo figlio due secondi di attesa prima
+di uscire, il risultato è:
+\begin{Command}
[piccardi@selidor sources]$ ./forktest -c2 3
+\end{Command}
+\begin{Terminal}[commandchars=\\\{\}]
Process 1972: forking 3 child
Spawned 1 child, pid 1973
Child 1 successfully executing
Child 3 successfully executing
Spawned 3 child, pid 1975
Go to next child
-[piccardi@selidor sources]$ Child 3, parent 1, exiting
+
+\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
Child 2, parent 1, exiting
Child 1, parent 1, exiting
-\end{Verbatim}
+\end{Terminal}
come si può notare in questo caso il processo padre si conclude prima dei
figli, tornando alla shell, che stampa il prompt sul terminale: circa due
secondi dopo viene stampato a video anche l'output dei tre figli che
Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e
memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati
dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione,
-mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. I
-processi che sono terminati, ma il cui stato di terminazione non è stato
-ancora ricevuto dal padre sono chiamati \index{zombie} \textit{zombie}, essi
+mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente.
+
+I processi che sono terminati, ma il cui stato di terminazione non è stato
+ancora ricevuto dal padre sono chiamati \itindex{zombie} \textit{zombie}, essi
restano presenti nella tabella dei processi ed in genere possono essere
identificati dall'output di \cmd{ps} per la presenza di una \texttt{Z} nella
colonna che ne indica lo stato (vedi tab.~\ref{tab:proc_proc_states}). Quando
-il padre effettuerà la lettura dello stato di uscita anche questa
-informazione, non più necessaria, verrà scartata e la terminazione potrà dirsi
-completamente conclusa.
+il padre effettuerà la lettura dello stato di terminazione anche questa
+informazione, non più necessaria, verrà scartata ed il processo potrà
+considerarso completamente concluso.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
sez.~\ref{sec:sess_job_control}), indicando al processo padre di aspettare 10
-secondi prima di uscire; in questo caso, usando \cmd{ps} sullo stesso
+secondi prima di uscire. In questo caso, usando \cmd{ps} sullo stesso
terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Verbatim}[fontsize=\footnotesize,xleftmargin=1cm,xrightmargin=1.5cm]
+\begin{Command}
[piccardi@selidor sources]$ ps T
+\end{Command}
+%$
+\begin{Terminal}
PID TTY STAT TIME COMMAND
419 pts/0 S 0:00 bash
568 pts/0 S 0:00 ./forktest -e10 3
570 pts/0 Z 0:00 [forktest <defunct>]
571 pts/0 Z 0:00 [forktest <defunct>]
572 pts/0 R 0:00 ps T
-\end{Verbatim}
-%$
-e come si vede, dato che non si è fatto nulla per riceverne lo
-stato di terminazione, i tre processi figli sono ancora presenti pur essendosi
-conclusi, con lo stato di \index{zombie} \textit{zombie} e l'indicazione che
-sono stati terminati.
+\end{Terminal}
+e come si vede, dato che non si è fatto nulla per riceverne lo stato di
+terminazione, i tre processi figli sono ancora presenti pur essendosi
+conclusi, con lo stato di \itindex{zombie} \textit{zombie} e l'indicazione che
+sono terminati (la scritta \texttt{defunct}).
-La possibilità di avere degli \index{zombie} \textit{zombie} deve essere
+La possibilità di avere degli \itindex{zombie} \textit{zombie} deve essere
tenuta sempre presente quando si scrive un programma che deve essere mantenuto
in esecuzione a lungo e creare molti figli. In questo caso si deve sempre
-avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in
+avere cura di far leggere l'eventuale stato di uscita di tutti i figli. In
genere questo si fa attraverso un apposito \textit{signal handler}, che chiama
-la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e
-sez.~\ref{sec:proc_wait}). Questa operazione è necessaria perché anche se gli
-\index{zombie} \textit{zombie} non consumano risorse di memoria o processore,
-occupano comunque una voce nella tabella dei processi, che a lungo andare
-potrebbe esaurirsi.
-
-Si noti che quando un processo adottato da \cmd{init} termina, esso non
-diviene uno \index{zombie} \textit{zombie}; questo perché una delle funzioni
-di \cmd{init} è appunto quella di chiamare la funzione \func{wait} per i
-processi cui fa da padre, completandone la terminazione. Questo è quanto
-avviene anche quando, come nel caso del precedente esempio con \cmd{forktest},
-il padre termina con dei figli in stato di \index{zombie} \textit{zombie}:
-alla sua terminazione infatti tutti i suoi figli (compresi gli \index{zombie}
-\textit{zombie}) verranno adottati da \cmd{init}, il quale provvederà a
-completarne la terminazione.
-
-Si tenga presente infine che siccome gli \index{zombie} \textit{zombie} sono
-processi già usciti, non c'è modo di eliminarli con il comando \cmd{kill};
-l'unica possibilità di cancellarli dalla tabella dei processi è quella di
-terminare il processo che li ha generati, in modo che \cmd{init} possa
-adottarli e provvedere a concluderne la terminazione.
-
+la funzione \func{wait}, (vedi sez.~\ref{sec:sig_sigchld} e
+sez.~\ref{sec:proc_wait}) di cui vedremo un esempio in
+fig.~\ref{fig:sig_sigchld_handl}.
+
+Questa operazione è necessaria perché anche se gli \itindex{zombie}
+\textit{zombie} non consumano risorse di memoria o processore, occupano
+comunque una voce nella tabella dei processi e se li si lascia accumulare a
+lungo quest'ultima potrebbe riempirsi, con l'impossibilità di lanciare nuovi
+processi.
+
+Si noti tuttavia che quando un processo adottato da \cmd{init} termina, non
+diviene mai uno \itindex{zombie} \textit{zombie}. Questo perché una delle
+funzioni di \cmd{init} è appunto quella di chiamare la funzione \func{wait}
+per i processi a cui fa da padre, completandone la terminazione. Questo è
+quanto avviene anche quando, come nel caso del precedente esempio con
+\cmd{forktest}, il padre termina con dei figli in stato di \itindex{zombie}
+\textit{zombie}. Questi scompaiono quando, alla terminazione del padre dopo i
+secondi programmati, tutti figli che avevamo generato, e che erano diventati
+\itindex{zombie} \textit{zombie}, vengono adottati da \cmd{init}, il quale
+provvede a completarne la terminazione.
+
+Si tenga presente infine che siccome gli \itindex{zombie} \textit{zombie} sono
+processi già terminati, non c'è modo di eliminarli con il comando \cmd{kill} o
+inviandogli un qualunque segnale di terminazione (l'argomento è trattato in
+sez.~\ref{sec:sig_termination}). L'unica possibilità di cancellarli dalla
+tabella dei processi è quella di terminare il processo che li ha generati, in
+modo che \cmd{init} possa adottarli e concluderne la terminazione.
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
consiste nella creazione di programmi di tipo server, in cui un processo
principale attende le richieste che vengono poi soddisfatte da una serie di
-processi figli. Si è già sottolineato al paragrafo precedente come in questo
-caso diventi necessario gestire esplicitamente la conclusione dei figli onde
-evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
-le funzioni deputate a questo compito sono principalmente due, la prima è
-\funcd{wait} ed il suo prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t wait(int *status)}
-
-Sospende il processo corrente finché un figlio non è uscito, o finché un
-segnale termina il processo o chiama una funzione di gestione.
-
-\bodydesc{La funzione restituisce il \acr{pid} del figlio in caso di successo
- e -1 in caso di errore; \var{errno} può assumere i valori:
+processi figli.
+
+Si è già sottolineato al paragrafo precedente come in questo caso diventi
+necessario gestire esplicitamente la conclusione dei figli onde evitare di
+riempire di \itindex{zombie} \textit{zombie} la tabella dei
+processi. Tratteremo in questa sezione le funzioni deputate a questo compito;
+la prima è \funcd{wait} ed il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t wait(int *status)}
+\fdesc{Attende la terminazione di un processo.}
+}
+{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
+ \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere
+ uno stato di terminazione.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
\end{errlist}}
-\end{functions}
-\noindent
+\end{funcproto}
-Questa funzione è presente fin dalle prime versioni di Unix; essa ritorna non
-appena un qualunque processo figlio termina. Se un figlio è già terminato
-prima della chiamata la funzione ritorna immediatamente, se più di un figlio è
-già terminato occorre continuare chiamare la funzione più volte se si vuole
-recuperare lo stato di terminazione di tutti quanti.
+Questa funzione è presente fin dalle prime versioni di Unix ed è quella usata
+tradizionalmente per attendere la terminazione dei figli. La funzione sospende
+l'esecuzione del processo corrente e ritorna non appena un qualunque processo
+figlio termina. Se un figlio è già terminato prima della sua chiamata la
+funzione ritorna immediatamente, se più processi figli sono già terminati
+occorrerà continuare a chiamare la funzione più volte fintanto che non si è
+recuperato lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
-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 della
-funzione sarà impostato al \acr{pid} del processo di cui si è ricevuto lo
-stato di terminazione, cosa che permette di identificare qual è il figlio che
-è terminato.
+(come \itindex{value~result~argument} \textit{value result argument}) 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 della funzione sarà impostato
+al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa
+che permette di identificare qual è il figlio che è terminato.
+
+\itindend{termination~status}
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
-necessario attendere la conclusione di un processo specifico occorrerebbe
-predisporre un meccanismo che tenga conto dei processi già terminati, e
-provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
-sia ancora attivo.
+necessario attendere la conclusione di uno specifico processo fra tutti quelli
+esistenti occorre predisporre un meccanismo che tenga conto di tutti processi
+che sono terminati, e provveda a ripetere la chiamata alla funzione nel caso
+il processo cercato non risulti fra questi. Se infatti il processo cercato è
+già terminato e se è già ricevuto lo stato di uscita senza registrarlo, la
+funzione non ha modo di accorgersene, e si continuerà a chiamarla senza
+accorgersi che quanto interessava è già accaduto.
Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
effettua lo stesso servizio, ma dispone di una serie di funzionalità più
\code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
\&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
\funcd{waitpid}, il cui prototipo è:
-\begin{functions}
-\headdecl{sys/types.h}
-\headdecl{sys/wait.h}
-\funcdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
-Attende la conclusione di un processo figlio.
-\bodydesc{La funzione restituisce il \acr{pid} del processo che è uscito, 0 se
- è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e
- -1 per un errore, nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.}
+}
+{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso
+ di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il
+ processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
+ assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
-\end{functions}
+\end{funcproto}
La prima differenza fra le due funzioni è che con \func{waitpid} si può
specificare in maniera flessibile quale processo attendere, sulla base del
Il comportamento di \func{waitpid} può inoltre essere modificato passando alla
funzione delle opportune opzioni tramite l'argomento \param{options}; questo
-deve essere specificato come maschera binaria dei flag riportati nella prima
-parte in tab.~\ref{tab:proc_waitpid_options} che possono essere combinati fra
-loro con un OR aritmetico. Nella seconda parte della stessa tabella si sono
-riportati anche alcuni valori non standard specifici di Linux, che consentono
-un controllo più dettagliato per i processi creati con la \textit{system call}
-generica \func{clone} (vedi sez.~\ref{sec:process_clone}) usati principalmente
-per la gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
-sez.~\ref{sec:thread_xxx}).
+deve essere specificato come maschera binaria delle costanti riportati nella
+prima parte in tab.~\ref{tab:proc_waitpid_options} che possono essere
+combinate fra loro con un OR aritmetico. Nella seconda parte della stessa
+tabella si sono riportati anche alcuni valori non standard specifici di Linux,
+che consentono un controllo più dettagliato per i processi creati con la
+\textit{system call} generica \func{clone} (vedi sez.~\ref{sec:process_clone})
+usati principalmente per la gestione della terminazione dei \itindex{thread}
+\textit{thread} (vedi sez.~\ref{sec:thread_xxx}).
\begin{table}[!htb]
\centering
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{WNOHANG} & La funzione ritorna immediatamente anche se non è
In generale in un programma non si vuole essere forzati ad attendere la
conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto
questo serve solo per leggerne lo stato di chiusura (ed evitare eventualmente
-la presenza di \index{zombie} \textit{zombie}).
+la presenza di \itindex{zombie} \textit{zombie}).
Per questo la modalità più comune di chiamare queste funzioni è quella di
utilizzarle all'interno di un \textit{signal handler} (vedremo un esempio di
controllo molto più preciso sui possibili cambiamenti di stato dei processi
figli e più dettagli sullo stato di uscita; la funzione è \funcd{waitid} ed il
suo prototipo è:
-\begin{functions}
- \headdecl{sys/types.h}
-
- \headdecl{sys/wait.h}
-
- \funcdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int
- options)}
- Attende la conclusione di un processo figlio.
-
- \bodydesc{La funzione restituisce 0 in caso di successo e -1 per un errore,
- nel qual caso \var{errno} assumerà i valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/wait.h}
+\fdecl{int waitid(idtype\_t idtype, id\_t id, siginfo\_t *infop, int options)}
+\fdesc{Attende il cambiamento di stato di un processo figlio.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINTR}] se non è stata specificata l'opzione \const{WNOHANG} e
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
non è figlio del processo chiamante.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
-\end{functions}
+\end{funcproto}
La funzione prevede che si specifichi quali processi si intendono osservare
usando i due argomenti \param{idtype} ed \param{id}; il primo indica se ci si
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{P\_PID} & Indica la richiesta di attendere per un processo figlio
\footnotesize
\begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Macro} & \textbf{Descrizione}\\
+ \textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
\const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
sez.~\ref{sec:sys_res_limits}) 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 sono:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/times.h}
+\fhead{sys/resource.h}
+\fhead{sys/wait.h}
+\fdecl{int wait4(pid\_t pid, int *status, int options, struct rusage *rusage))}
+\fdesc{Attende il cambiamento di stato di un processo figlio, riportando l'uso
+ delle risorsr.}
+}
+{La funzione ha gli stessi valori di ritorno e codici di errore di
+ \func{waitpid}. }
+\end{funcproto}
+
+
\begin{functions}
\headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
\headdecl{sys/resource.h}
sez.~\ref{sec:sys_resource_use}) per ottenere le risorse di sistema usate da un
processo; la sua definizione è riportata in fig.~\ref{fig:sys_rusage_struct}.
+
\subsection{La funzione \func{exec} e le funzioni di esecuzione dei programmi}
\label{sec:proc_exec}
Tutte queste possibilità sono caratterizzate da un diverso \textsl{stato} del
processo, in Linux un processo può trovarsi in uno degli stati riportati in
tab.~\ref{tab:proc_proc_states}; ma soltanto i processi che sono nello stato
-\textbf{Runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
+\textit{runnable} concorrono per l'esecuzione. Questo vuol dire che, qualunque
sia la sua priorità, un processo non potrà mai essere messo in esecuzione
fintanto che esso si trova in uno qualunque degli altri stati.
\textbf{Stato} & \texttt{STAT} & \textbf{Descrizione} \\
\hline
\hline
- \textbf{Runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
+ \textit{runnable}& \texttt{R} & Il processo è in esecuzione o è pronto ad
essere eseguito (cioè è in attesa che gli
venga assegnata la CPU).\\
- \textbf{Sleep} & \texttt{S} & Il processo è in attesa di un
+ \textit{sleep} & \texttt{S} & Il processo è in attesa di un
risposta dal sistema, ma può essere
interrotto da un segnale.\\
- \textbf{Uninterrutible Sleep}& \texttt{D} & Il processo è in
+ \textit{uninterrutible sleep}& \texttt{D} & Il processo è in
attesa di un risposta dal sistema (in
genere per I/O), e non può essere
interrotto in nessuna circostanza.\\
- \textbf{Stopped} & \texttt{T} & Il processo è stato fermato con un
+ \textit{stopped} & \texttt{T} & Il processo è stato fermato con un
\signal{SIGSTOP}, o è tracciato.\\
- \textbf{Zombie}\index{zombie} & \texttt{Z} & Il processo è terminato ma il
+ \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
suo stato di terminazione non è ancora
stato letto dal padre.\\
- \textbf{Killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
+ \textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
2.6.25, sostanzialmente identico
- all'\textbf{Uninterrutible Sleep} con la
+ all'\textit{uninterrutible sleep} con la
sola differenza che il processo può
terminato con \signal{SIGKILL} (usato per
lo più per NFS).\\
(entro certi limiti, che vedremo più avanti) la priorità dei propri processi.
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
-di \var{nice} del processo; tuttavia la system call di Linux non segue questa
-convenzione e restituisce sempre 0 in caso di successo e $-1$ in caso di
-errore; questo perché $-1$ è un valore di \var{nice} legittimo e questo
-comporta una confusione con una eventuale condizione di errore. La system call
-originaria inoltre non consente, se non dotati di adeguati privilegi, di
-diminuire un valore di \var{nice} precedentemente innalzato.
+di \var{nice} del processo; tuttavia la \textit{system call} di Linux non
+segue questa convenzione e restituisce sempre 0 in caso di successo e $-1$ in
+caso di errore; questo perché $-1$ è un valore di \var{nice} legittimo e
+questo comporta una confusione con una eventuale condizione di errore. La
+\textit{system call} originaria inoltre non consente, se non dotati di
+adeguati privilegi, di diminuire un valore di \var{nice} precedentemente
+innalzato.
Fino alle \acr{glibc} 2.2.4 la funzione di libreria riportava direttamente il
-risultato dalla system call, violando lo standard, per cui per ottenere il
-nuovo valore occorreva una successiva chiamata alla funzione
+risultato dalla \textit{system call}, violando lo standard, per cui per
+ottenere il nuovo valore occorreva una successiva chiamata alla funzione
\func{getpriority}. A partire dalla \acr{glibc} 2.2.4 \func{nice} è stata
-reimplementata e non viene più chiamata la omonima system call, con questa
-versione viene restituito come valore di ritorno il valore di \var{nice}, come
-richiesto dallo standard.\footnote{questo viene fatto chiamando al suo interno
- \func{setpriority}, che tratteremo a breve.} In questo caso l'unico modo
-per rilevare in maniera affidabile una condizione di errore è quello di
-azzerare \var{errno} prima della chiamata della funzione e verificarne il
-valore quando \func{nice} restituisce $-1$.
+reimplementata e non viene più chiamata la omonima \textit{system call}, con
+questa versione viene restituito come valore di ritorno il valore di
+\var{nice}, come richiesto dallo standard.\footnote{questo viene fatto
+ chiamando al suo interno \func{setpriority}, che tratteremo a breve.} In
+questo caso l'unico modo per rilevare in maniera affidabile una condizione di
+errore è quello di azzerare \var{errno} prima della chiamata della funzione e
+verificarne il valore quando \func{nice} restituisce $-1$.
Per leggere il valore di \textit{nice} di un processo occorre usare la
funzione \funcd{getpriority}, derivata da BSD; il suo prototipo è:
nel qual caso \var{errno} può assumere i valori:
\begin{errlist}
\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
- \item[\errcode{ENOSYS}] la system call non è stata implementata.
+ \item[\errcode{ENOSYS}] la \textit{system call} non è stata implementata.
\end{errlist}}
\end{prototype}
\textit{hard CPU affinity}, in contrasto con quella fornita dallo scheduler,
detta \textit{soft CPU affinity}, che di norma indica solo una preferenza,
non un requisito assoluto.} e per poter risolvere questo tipo di
-problematiche nei nuovi kernel\footnote{le due system call per la gestione
- della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8, e le
- funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
-l'opportuna infrastruttura ed una nuova system call che permette di impostare
-su quali processori far eseguire un determinato processo attraverso una
-\textsl{maschera di affinità}. La corrispondente funzione di libreria è
+problematiche nei nuovi kernel\footnote{le due \textit{system call} per la
+ gestione della \textit{CPU affinity} sono state introdotte nel kernel 2.5.8,
+ e le funzioni di libreria nelle \textsl{glibc} 2.3.} è stata introdotta
+l'opportuna infrastruttura ed una nuova \textit{system call} che permette di
+impostare su quali processori far eseguire un determinato processo attraverso
+una \textsl{maschera di affinità}. La corrispondente funzione di libreria è
\funcd{sched\_setaffinity} ed il suo prototipo è:
\begin{prototype}{sched.h}
{int sched\_setaffinity (pid\_t pid, unsigned int cpusetsize, const
Questa funzione e la corrispondente \func{sched\_setaffinity} hanno una storia
-abbastanza complessa, la system call prevede l'uso di due ulteriori argomenti
-di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask}, che
-corrispondono al fatto che la implementazione effettiva usa una semplice
+abbastanza complessa, la \textit{system call} prevede l'uso di due ulteriori
+argomenti di tipo \texttt{unsigned int len} e \texttt{unsigned long *mask},
+che corrispondono al fatto che la implementazione effettiva usa una semplice
maschera binaria. Quando le funzioni vennero incluse nelle \acr{glibc}
assunsero invece il prototipo appena mostrato. A complicare la cosa si
aggiunge il fatto che nella versione 2.3.3 delle \acr{glibc} l'argomento
della guida, si può saltare questa sezione in una prima lettura, tornando su
di essa in un secondo tempo.
-\subsection{La system call \func{clone}}
+\subsection{La \textit{system call} \func{clone}}
\label{sec:process_clone}
La funzione tradizionale con cui creare un nuovo processo in un sistema
lo stato corrente del flag che controlla la effettiva generazione dei
\itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
2.3.20.
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianess} del processo
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
\const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
\const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
PowerPC). Introdotta a partire dal kernel 2.6.18, solo per architettura
PowerPC.
-\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianess} del
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianness} del
processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
essere passata come di tipo \ctyp{(int *)}. Introdotta a partire dal kernel
2.6.18, solo su PowerPC.
cap.~\ref{cha:IPC}) o nelle operazioni con i file (vedremo alcuni esempi in
sez.~\ref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
funzioni di libreria per compiere le operazioni necessarie è garanzia
-sufficiente di atomicità in quanto le system call con cui esse sono realizzate
-non possono essere interrotte (o subire interferenze pericolose) da altri
-processi.
+sufficiente di atomicità in quanto le \textit{system call} con cui esse sono
+realizzate non possono essere interrotte (o subire interferenze pericolose) da
+altri processi.
Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
-stesso processo, e pure alcune system call, possono essere interrotti in
-qualunque momento, e le operazioni di un eventuale \textit{signal handler}
+stesso processo, e pure alcune \textit{system call}, possono essere interrotti
+in qualunque momento, e le operazioni di un eventuale \textit{signal handler}
sono compiute nello stesso spazio di indirizzi del processo. Per questo, anche
il solo accesso o l'assegnazione di una variabile possono non essere più
operazioni atomiche (torneremo su questi aspetti in
% LocalWords: SIGKILL static RLIMIT preemption PREEMPT VOLUNTARY IDLE RTPRIO
% LocalWords: completely fair compat uniform CFQ queuing elevator dev cfq RT
% LocalWords: documentation block syscall ioprio IPRIO CLASS class best effort
-% LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big
-% LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianess endian flags
+% LocalWords: refresh semop dnotify MADV DONTFORK prctl WCLONE WALL big mount
+% LocalWords: WNOTHREAD DUMPABLE KEEPCAPS IRIX CAPBSET endianness endian flags
% LocalWords: little PPC PowerPC FPEMU NOPRINT SIGFPE FPEXC point FP SW malloc
% LocalWords: exception EXC ENABLE OVF overflow UND underflow RES INV DISABLED
-% LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM
+% LocalWords: NONRECOV ASYNC KEEP securebits NAME NUL PDEATHSIG SECCOMP VM FS
% LocalWords: secure computing sigreturn TIMING STATISTICAL TSC MCE conditions
% LocalWords: timestamp Stamp SIGSEGV UNALIGN SIGBUS MCEERR AO failure early
+% LocalWords: namespace vsyscall SETTID FILES NEWIPC NEWNET NEWNS NEWPID ptid
+% LocalWords: NEWUTS SETTLS SIGHAND SYSVSEM UNTRACED tls ctid CLEARTID
%%% Local Variables:
%%% mode: latex
projects / gapil.git / commitdiff