X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=prochand.tex;h=a87e848a7499201135d65446d1e73b5132894443;hp=b09fdfd62b2aee127b7c2f047c8634258907d241;hb=8e2e77dff8f3cffb28ddf982280dff6fc015eb19;hpb=975734ea91207bfbf931d2dc3bff62510087d5ba diff --git a/prochand.tex b/prochand.tex index b09fdfd..a87e848 100644 --- a/prochand.tex +++ b/prochand.tex @@ -490,7 +490,7 @@ codice. Un secondo aspetto molto importante nella creazione dei processi figli è 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 +(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} @@ -524,8 +524,8 @@ Go to next child 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} per l'interfaccia -nativa Unix ed in cap.~\ref{cha:files_std_interface} per la standardizzazione +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 @@ -549,22 +549,23 @@ 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_std_descr}.} del padre viene + 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. + 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 @@ -606,7 +607,7 @@ comune dopo l'esecuzione di una \func{fork} è la seguente: \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 @@ -1621,7 +1622,7 @@ nell'esecuzione della funzione \func{exec}, queste sono: 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 @@ -2153,7 +2154,7 @@ Le ultime funzioni che esamineremo sono quelle che permettono di operare sui 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. @@ -2822,7 +2823,7 @@ rispettivamente 1 e 99. \begin{figure}[!htbp] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.5\textwidth} \includestruct{listati/sched_param.c} \end{minipage} \normalsize @@ -3465,15 +3466,15 @@ della priorità da impostare con l'argomento \param{ioprio} di \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 @@ -3917,10 +3918,10 @@ indicare la unità di esecuzione generica messa a disposizione del kernel che Oltre a questo la funzione consente, ad uso delle nuove funzionalità di virtualizzazione dei processi, di creare nuovi \textit{namespace} per una -serie di proprietà generali dei processi (come l'elenco dei PID, l'albero dei -file, i \itindex{mount~point} \textit{mount point}, la rete, ecc.), che -consentono di creare gruppi di processi che vivono in una sorta di spazio -separato dagli altri, che costituisce poi quello che viene chiamato un +serie di proprietà generali dei processi (come l'elenco dei \ids{PID}, +l'albero dei file, i \itindex{mount~point} \textit{mount point}, la rete, +ecc.), che consentono di creare gruppi di processi che vivono in una sorta di +spazio separato dagli altri, che costituisce poi quello che viene chiamato un \textit{container}. La \textit{system call} richiede soltanto due argomenti: il @@ -4148,11 +4149,11 @@ Nel caso dell'interazione fra processi la situazione è molto più semplice, ed 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