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}
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
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
\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
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
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.
\begin{figure}[!htbp]
\footnotesize \centering
- \begin{minipage}[c]{\textwidth}
+ \begin{minipage}[c]{0.5\textwidth}
\includestruct{listati/sched_param.c}
\end{minipage}
\normalsize
\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
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
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
projects / gapil.git / blobdiff