%% prochand.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2013 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\begin{figure}[!htb]
\footnotesize
-\begin{Command}
-[piccardi@gont piccardi]$ pstree -n
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+[piccardi@gont piccardi]$ \textbf{pstree -n}
init-+-keventd
|-kapm-idled
|-kreiserfsd
|-5*[getty]
|-snort
`-wwwoffled
-\end{Terminal}
+\end{Console}
%$
\caption{L'albero dei processi, così come riportato dal comando
\cmd{pstree}.}
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 \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
- compilazione del kernel, con un default di 250 e valori possibili di 100,
- 250, 1000 e dal 2.6.20 anche 300 (che è divisibile per le frequenze 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.
+eseguito in occasione di dell'invocazione di ogni \textit{system call} ed per
+ogni interrupt dall'hardware oltre che in una serie di altre occasioni, e può
+essere anche attivato esplicitamente. Il timer di sistema provvede comunque a
+che esso sia invocato periodicamente, generando un interrupt periodico secondo
+una frequenza predeterminata, specificata dalla costante \const{HZ} del kernel
+(torneremo su questo argomento in sez.~\ref{sec:sys_unix_time}), che assicura
+che lo \textit{scheduler} scheduler venga comunque eseguito ad intervalli
+regolari e possa prendere le sue decisioni.
+
A partire dal kernel 2.6.21 è stato introdotto anche un meccanismo
completamente diverso, detto \textit{tickless}, in cui non c'è più una
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}).
+sul numero totale di processi permessi all'utente, argomento che tratteremo in
+dettaglio in sez.~\ref{sec:sys_resource_limit}.
L'uso di \func{fork} avviene secondo due modalità principali; la prima è
quella in cui all'interno di un programma si creano processi figli cui viene
specificare attese (come si può notare in (\texttt{\small 17--19}) i valori
predefiniti specificano di non attendere), otterremo come risultato sul
terminale:
-\begin{Command}
-[piccardi@selidor sources]$ export LD_LIBRARY_PATH=./; ./forktest 3
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{export LD_LIBRARY_PATH=./; ./forktest 3}
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{Terminal}
+\end{Console}
+%$
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
(principalmente in sez.~\ref{sec: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}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest 3 > output}
+[piccardi@selidor sources]$ \textbf{cat output}
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{Terminal}
+\end{Console}
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 sez.~\ref{sec:file_unix_interface} per l'interfaccia
nativa Unix ed in sez.~\ref{sec:files_std_interface} per la standardizzazione
adottata nelle librerie del linguaggio C e valida per qualunque sistema
-operativo. 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.
+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.
+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 in memoria, la posizione corrente sul file è condivisa fra il
-padre e tutti i processi figli.
+(l'argomento dell'accesso concorrente ai file è trattato in dettaglio in
+sez.~\ref{sec:file_shared_access}), ma anche che, a differenza di quanto
+avviene per 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_fd}.} 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 \textit{file descriptor} (vedi sez.~\ref{sec:file_fd})
-dei file aperti nel processo padre (allo stesso modo in cui lo fa la funzione
-\func{dup}, trattata in sez.~\ref{sec:file_dup}), il che comporta che padre e
-figli condividono le stesse voci della \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.
+ così il file su cui di default un programma scrive i suoi dati in uscita,
+ tratteremo l'argomento in dettaglio in sez.~\ref{sec:file_fd}.} 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 \textit{file descriptor} (vedi
+sez.~\ref{sec:file_fd}) dei file aperti nel processo padre (allo stesso modo
+in cui lo fa la funzione \func{dup}, trattata in sez.~\ref{sec:file_dup}), il
+che comporta che padre e figli condividono le stesse voci della
+\itindex{file~table} \textit{file table} (tratteremo in dettaglio questi
+termini in sez.~\ref{sec:file_shared_access}) fra cui c'è anche la posizione
+corrente nel file.
In questo modo se un processo scrive su un file aggiornerà la posizione
corrente sulla \itindex{file~table} \textit{file table}, e tutti gli altri
\begin{itemize*}
\item i file aperti e gli eventuali flag di \itindex{close-on-exec}
\textit{close-on-exec} impostati (vedi sez.~\ref{sec:proc_exec} e
- sez.~\ref{sec:file_fcntl});
+ sez.~\ref{sec:file_fcntl_ioctl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
(vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
\item la maschera dei permessi di creazione dei file (vedi
sez.~\ref{sec:file_perm_management});
-\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
- azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
+\item la \index{maschera~dei~segnali} maschera dei segnali bloccati (vedi
+ sez.~\ref{sec:sig_sigmask}) e le azioni installate (vedi
+ sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
sez.~\ref{sec:ipc_sysv_shm});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
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=\\\{\}]
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{./forktest -c2 3}
Process 1972: forking 3 child
Spawned 1 child, pid 1973
Child 1 successfully executing
Spawned 3 child, pid 1975
Go to next child
-\textbf{[piccardi@selidor sources]$} Child 3, parent 1, exiting
+[piccardi@selidor sources]$ Child 3, parent 1, exiting
Child 2, parent 1, exiting
Child 1, parent 1, exiting
-\end{Terminal}
+\end{Console}
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
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
terminale (prima dello scadere dei 10 secondi) otterremo:
-\begin{Command}
-[piccardi@selidor sources]$ ps T
-\end{Command}
-%$
-\begin{Terminal}
+\begin{Console}
+[piccardi@selidor sources]$ \textbf{ps T}
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{Terminal}
+\end{Console}
+%$
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
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
-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}) 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.
+in esecuzione a lungo e creare molti processi figli. In questo caso si deve
+sempre avere cura di far leggere al programma l'eventuale stato di uscita di
+tutti i figli. Una modalità comune di farlo è attraverso l'utilizzo di un
+apposito \textit{signal handler} che chiami la funzione \func{wait}, (vedi
+sez.~\ref{sec:proc_wait}), ne esamineremo in dettaglio un esempio
+(fig.~\ref{fig:sig_sigchld_handl}) in sez.~\ref{sec:sig_sigchld}.
+
+La lettura degli stati di uscita è 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
+lasciano accumulare a lungo quest'ultima potrebbe esaurirsi, con la
+conseguente 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
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.
+sez.~\ref{sec:sig_termination}). Qualora ci si trovi in questa situazione
+l'unica possibilità di cancellarli dalla tabella dei processi è quella di
+terminare il processo che li ha generati e che non sta facendo il suo lavoro,
+in modo che \cmd{init} possa adottarli e concluderne correttamente la
+terminazione.
+
+Si tenga anche presente che la presenza di \textit{zombie} nella tabella dei
+processi non è sempre indice di un qualche malfunzionamento, in una macchina
+con molto carico infatti può esservi una presenza temporanea dovuta al fatto
+che il processo padre ancora non ha avuto il tempo di gestirli.
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
lo \itindex{exit~status} stato di uscita del processo, e gli altri per
indicare il segnale che ha causato la terminazione (in caso di conclusione
anomala), uno per indicare se è stato generato un \itindex{core~dump}
-\textit{core dump}, ecc.\footnote{le definizioni esatte si possono trovare in
- \file{<bits/waitstatus.h>} ma questo file non deve mai essere usato
- direttamente, esso viene incluso attraverso \file{<sys/wait.h>}.}
+\textit{core dump} (vedi sez.~\ref{sec:sig_standard}), ecc.\footnote{le
+ definizioni esatte si possono trovare in \file{<bits/waitstatus.h>} ma
+ questo file non deve mai essere usato direttamente, esso viene incluso
+ attraverso \file{<sys/wait.h>}.}
\begin{table}[!htb]
\centering
\label{tab:proc_waitid_idtype}
\end{table}
-Come per \func{waitpid} anche il comportamento di \func{waitid} viene
+Come per \func{waitpid} anche il comportamento di \func{waitid} è
controllato dall'argomento \param{options}, da specificare come maschera
binaria dei valori riportati in tab.~\ref{tab:proc_waitid_options}. Benché
alcuni di questi siano identici come significato ed effetto ai precedenti di
\const{CLD\_STOPPED}, \const{CLD\_CONTINUED}, \const{CLD\_TRAPPED} e
\const{CLD\_DUMPED} a indicare la ragione del ritorno della funzione, il cui
significato è, nell'ordine: uscita normale, terminazione da segnale,
- processo fermato, processo riavviato, processo terminato in \textit{core
- dump}.
+ processo fermato, processo riavviato, processo terminato in
+ \itindex{core~dump} \textit{core dump} (vedi sez.~\ref{sec:sig_standard}).
\end{basedescript}
Infine Linux, seguendo un'estensione di BSD, supporta altre due funzioni per
famiglia di funzioni) che possono essere usate per questo compito, in realtà
(come mostrato in fig.~\ref{fig:proc_exec_relat}), tutte queste funzioni sono
tutte varianti che consentono di invocare in modi diversi, semplificando il
-passaggio degli argomenti, la \textit{system call} \funcd{execve}, il cui
+passaggio degli argomenti, la funzione di sistema \funcd{execve}, il cui
prototipo è:
\begin{funcproto}{
per indicare il nome del file che contiene il programma che verrà eseguito.
\begin{figure}[!htb]
- \centering \includegraphics[width=10cm]{img/exec_rel}
+ \centering \includegraphics[width=9cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}.}
\label{fig:proc_exec_relat}
\end{figure}
% TODO ===========Importante=============
% TODO questo sotto è incerto, verificare
% TODO ===========Importante=============
-\item la maschera dei segnali (si veda sez.~\ref{sec:sig_sigmask}).
+\item la \index{maschera~dei~segnali} maschera dei segnali (si veda
+ sez.~\ref{sec:sig_sigmask}).
\end{itemize*}
Una serie di proprietà del processo originale, che non avrebbe senso mantenere
\item le mappature dei file in memoria (vedi sez.~\ref{sec:file_memory_map});
\item i segmenti di memoria condivisa SysV (vedi sez.~\ref{sec:ipc_sysv_shm})
e POSIX (vedi sez.~\ref{sec:ipc_posix_shm});
-\item i \textit{memory lock} (vedi sez.~\ref{sec:proc_mem_lock});
+\item i \itindex{memory~locking} \textit{memory lock} (vedi
+ sez.~\ref{sec:proc_mem_lock});
\item le funzioni registrate all'uscita (vedi sez.~\ref{sec:proc_atexit});
\item i semafori e le code di messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_sem} e sez.~\ref{sec:ipc_posix_mq});
La gestione dei file aperti nel passaggio al nuovo programma lanciato con
\func{exec} dipende dal valore che ha il flag di \itindex{close-on-exec}
-\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl}) per ciascun
+\textit{close-on-exec} (vedi sez.~\ref{sec:file_fcntl_ioctl}) per ciascun
\textit{file descriptor}. I file per cui è impostato vengono chiusi, tutti gli
altri file restano aperti. Questo significa che il comportamento predefinito è
che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
del programma per caricare le librerie necessarie ed effettuare il link
-dell'eseguibile.\footnote{il formato è ormai in completo disuso, per cui è
- molto probabile che non il relativo supporto non sia disponibile.} Se il
-programma è in formato ELF per caricare le librerie dinamiche viene usato
-l'interprete indicato nel segmento \const{PT\_INTERP} previsto dal formato
-stesso, in genere questo è \sysfile{/lib/ld-linux.so.1} per programmi
-collegati con la \acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi
-collegati con la \acr{glibc}.
+dell'eseguibile; il formato è ormai in completo disuso, per cui è molto
+probabile che non il relativo supporto non sia disponibile. Se il programma è
+in formato ELF per caricare le librerie dinamiche viene usato l'interprete
+indicato nel segmento \const{PT\_INTERP} previsto dal formato stesso, in
+genere questo è \sysfile{/lib/ld-linux.so.1} per programmi collegati con la
+\acr{libc5}, e \sysfile{/lib/ld-linux.so.2} per programmi collegati con la
+\acr{glibc}.
Infine nel caso il programma che si vuole eseguire sia uno script e non un
binario, questo deve essere un file di testo che deve iniziare con una linea
\end{Example}
dove l'interprete indicato deve essere un eseguibile binario e non un altro
script, che verrà chiamato come se si fosse eseguito il comando
-\cmd{interpreter [argomenti] filename}.\footnote{si tenga presente che con
- Linux quanto viene scritto come \texttt{argomenti} viene passato
- all'interprete come un unico argomento con una unica stringa di lunghezza
- massima di 127 caratteri e se questa dimensione viene ecceduta la stringa
- viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
- comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
- nei vari argomenti e se è troppo lunga restituisce un errore di
- \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su
- \url{http://www.in-ulm.de/~mascheck/various/shebang/}.}
+\cmd{interpreter [argomenti] filename}.
+
+Si tenga presente che con Linux quanto viene scritto come \texttt{argomenti}
+viene passato all'interprete come un unico argomento con una unica stringa di
+lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la
+stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi
+comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide
+nei vari argomenti e se è troppo lunga restituisce un errore di
+\const{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
+sistemi unix-like si trova su
+\url{http://www.in-ulm.de/~mascheck/various/shebang/}.
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basata la gestione tradizionale dei processi in Unix: con \func{fork} si crea
gruppi supplementari cui un utente può appartenere. Ogni processo può avere
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
gruppi secondari può essere ottenuto con \func{sysconf} (vedi
- sez.~\ref{sec:sys_sysconf}), leggendo il parametro
+ sez.~\ref{sec:sys_limits}), leggendo il parametro
\texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
\hline
\const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
\const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group}
- \textit{process group} \\
+ \textit{process group}\\
\const{PRIO\_USER} & \type{uid\_t} & utente \\
\hline
\end{tabular}
\const{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
\const{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
ulteriore di lavoro \textit{CPU
- intensive} (dal kernel 2.6.16)\\
+ intensive} (dal kernel 2.6.16).\\
\const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
- bassa (dal kernel 2.6.23)\\
+ bassa (dal kernel 2.6.23).\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{policy} per la funzione
\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.5\textwidth}
\includestruct{listati/sched_param.c}
\end{minipage}
\normalsize
la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
-Lo standard POSIX.1b prevede comunque che l'intervallo dei valori delle
+Lo standard POSIX.1b prevede inoltre che l'intervallo dei valori delle
priorità statiche possa essere ottenuto con le funzioni di sistema
\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
prototipi sono:
\hline
\hline
\macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
\macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
- & dato il valore di una priorità come
+ & Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della priorità.\\
\macro{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
- & dato un valore di priorità ed una classe
+ & Dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\hline
Introdotta a partire dal kernel 2.6.23, disponibile solo se si è abilitato
il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
+% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
+% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
+% Documentation/prctl/seccomp_filter.txt
+
+
\item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
lo stato corrente del \textit{secure computing mode}, al momento attuale la
funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
memoria. Tutti gli argomenti non utilizzati (al momento tutti) devono essere
nulli pena la ricezione di un errore di \errval{EINVAL}. Introdotta a
partire dal kernel 2.6.32.
+% TODO: verificare questa parte
+\item[\const{PR\_SET\_CHILD\_SUBREAPER}] Imposta il processo indicato con il
+ \ids{PID} specificato da \param{arg2} come nuovo ``\textsl{genitore
+ adottivo}'' per tutti i processi discendenti del chiamante che
+ diventeranno orfani, sostituendo in questo ruolo \cmd{init} (si ricordi
+ quanto illustrato in sez.~\ref{sec:proc_termination}). Introdotta a partire
+ dal kernel 3.4.
+\item[\const{PR\_GET\_CHILD\_SUBREAPER}] Ottiene il \ids{PID} del processo a
+ cui vengono assegnati come figli gli orfani del processo
+ corrente. Introdotta a partire dal kernel 3.4.
+ % TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
+ % * Documentation/prctl/seccomp_filter.txt
+ % * http://lwn.net/Articles/475043/
+
\label{sec:prctl_operation}
\end{basedescript}
memoria, la \textit{system call}, a differenza della funzione di libreria che
vedremo a breve, consente anche di passare per \param{child\_stack} il valore
\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
-processo, questo ottiene un suo nuovo spazio degli indirizzi,\footnote{è
- sottinteso cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo
- a breve.} ed in questo caso si applica la semantica del
-\itindex{copy~on~write} \textit{copy on write} illustrata in
-sez.~\ref{sec:proc_fork}, per cui le pagine dello \textit{stack} verranno
-automaticamente copiate come le altre e il nuovo processo avrà un suo
-\textit{stack} totalmente indipendente da quello del padre.
+processo, questo ottiene un suo nuovo spazio degli indirizzi (è sottinteso
+cioè che non si stia usando il flag \const{CLONE\_VM} che vedremo a breve) ed
+in questo caso si applica la semantica del \itindex{copy~on~write}
+\textit{copy on write} illustrata in sez.~\ref{sec:proc_fork}, per cui le
+pagine dello \textit{stack} verranno automaticamente copiate come le altre e
+il nuovo processo avrà un suo \textit{stack} totalmente indipendente da quello
+del padre.
Dato che l'uso principale della nuova \textit{system call} è quello relativo
alla creazione dei \textit{thread}, la \acr{glibc} definisce una funzione di
La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato
\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo
al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei
-un processo.
+un processo ordinario e non un \textit{thread}.
Il comportamento di \func{clone}, che si riflette sulle caratteristiche del
nuovo processo da essa creato, è controllato principalmente
\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
-\item[\const{CLONE\_CHILD\_SETTID}]
-\item[\const{CLONE\_FILES}]
-\item[\const{CLONE\_FS}]
+ all'indirizzo dato dall'argomento \param{ctid}, eseguendo un riattivazione
+ del \textit{futex} (vedi sez.~\ref{sec:xxx_futex}) a quell'indirizzo; questo
+ flag viene utilizzato dalla librerie di gestione dei \textit{thread}.
+\item[\const{CLONE\_CHILD\_SETTID}] scrive il \ids{TID} del \textit{thread}
+ figlio all'indirizzo dato dall'argomento \param{ctid}. Questo flag viene
+ utilizzato dalla librerie di gestione dei \textit{thread}.
+\item[\const{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
+ padre la \itindex{file~descriptor~table} \textit{file descriptor table}
+ (vedi sez.~\ref{sec:file_fd}), questo significa che ogni \textit{file
+ descriptor} aperto da un processo verrà visto anche dall'altro e che ogni
+ chiusura o cambiamento dei \textit{file descriptor flag} di un \textit{file
+ descriptor} verrà per entrambi.
+
+ Se non viene impostato il processo figlio eredita una copia della
+ \itindex{file~descriptor~table} \textit{file descriptor table} del padre e
+ vale la semantica classica della gestione dei \textit{file descriptor}, che
+ costituisce il comportamento ordinario di un sistema unix-like e che
+ illustreremo in dettaglio in sez.~\ref{sec:file_shared_access}.
+
+\item[\const{CLONE\_FS}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre le informazioni
+
\item[\const{CLONE\_IO}]
\item[\const{CLONE\_NEWIPC}]
\item[\const{CLONE\_NEWNET}]
\end{basedescript}
-%TODO trattare unshare
+%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
+%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
+% https://lwn.net/Articles/478111/
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
Da fare
% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
+% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
+% http://lwn.net/Articles/529060/)
+% TODO: trattare PTRACE_GETSIGMASK e PTRACE_SETSIGMASK introdotte con il
+% kernel 3.11
+
\subsection{La gestione delle operazioni in virgola mobile}
% le pagine di manuale relative
% vedere anche dove metterle...
+% \subsection{La gestione dei moduli}
+% \label{sec:kernel_modules}
+
+% da fare
+
+%TODO trattare init_module e finit_module (quest'ultima introdotta con il
+%kernel 3.8)
+
+
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
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 \textit{system call} con cui esse sono
-realizzate non possono essere interrotte (o subire interferenze pericolose) da
-altri processi.
+sez.~\ref{sec:file_shared_access}). In questi casi in genere l'uso delle
+appropriate funzioni di libreria per compiere le operazioni necessarie è
+garanzia 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 \textit{system call}, possono essere interrotti
% LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF
% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR
% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector
-% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker
+% LocalWords: list environ NULL umask utime cutime ustime fcntl linker
% LocalWords: opendir libc interpreter FreeBSD capabilities mandatory access
% LocalWords: control MAC SELinux security modules LSM superuser uid gid saved
% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr