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
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
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
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
\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
\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
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
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.
\label{sec:prctl_operation}
\end{basedescript}
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