%% prochand.tex
%%
-%% Copyright (C) 2000-2015 by Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2018 by 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",
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
-\itindex{Process~ID~(PID)} \textit{Process ID} o, più brevemente, \ids{PID},
-assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid}) quando il
-processo viene creato.
+\textit{Process ID} o, più brevemente, \ids{PID}, assegnato in forma
+progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato.
Una seconda caratteristica di un sistema unix-like è che la generazione di un
processo è un'operazione separata rispetto al lancio di un programma. In
\ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che
non rientrano in questa classificazione.}
+\itindbeg{process~table}
+
Il kernel mantiene una tabella dei processi attivi, la cosiddetta
-\itindex{process~table} \textit{process table}. Per ciascun processo viene
-mantenuta una voce in questa tabella, costituita da una struttura
-\kstruct{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}.
+\textit{process table}. Per ciascun processo viene mantenuta una voce in
+questa tabella, costituita da una struttura \kstruct{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 \texttt{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}
- \caption{Schema semplificato dell'architettura delle strutture usate dal
- kernel nella gestione dei processi.}
+ \caption{Schema semplificato dell'architettura delle strutture (
+ \kstructd{task\_struct}, \kstructd{fs\_struct}, \kstructd{file\_struct})
+ usate dal kernel nella gestione dei processi.}
\label{fig:proc_task_struct}
\end{figure}
+\itindend{process~table}
+
% TODO la task_struct è cambiata per qualche dettaglio vedi anche
% http://www.ibm.com/developerworks/linux/library/l-linux-process-management/
% TODO completare la parte su quando viene chiamato lo scheduler.
\subsection{Gli identificatori dei processi}
\label{sec:proc_pid}
+\itindbeg{Process~ID~(PID)}
+
Come accennato nella sezione precedente ogni processo viene identificato dal
sistema da un numero identificativo univoco, il \textit{process ID} o
\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un
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 \ids{PID} è stato
- modificato ed il valore massimo è impostabile attraverso il file
- \sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a
-riservare i \ids{PID} più bassi ai processi eseguiti direttamente dal kernel.
-Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di
-avvio (\cmd{init}) ha sempre il \ids{PID} uguale a uno.
+ \constd{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 \textit{thread} anche il
+ meccanismo di allocazione dei \ids{PID} è stato modificato ed il valore
+ massimo è impostabile attraverso il file \sysctlfiled{kernel/pid\_max} e di
+ default vale 32768.} che serve a riservare i \ids{PID} più bassi ai processi
+eseguiti direttamente dal kernel. Per questo motivo, come visto in
+sez.~\ref{sec:proc_hierarchy}, il processo di avvio (\cmd{init}) ha sempre il
+\ids{PID} uguale a uno.
+
+\itindbeg{Parent~Process~ID~(PPID)}
Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui
sono stati creati, questo viene chiamato in genere \ids{PPID} (da
-\itindex{Parent~Process~ID~(PPID)} \textit{Parent Process ID}). Questi due
-identificativi possono essere ottenuti usando le due funzioni di sistema
-\funcd{getpid} e \funcd{getppid}, i cui prototipi sono:
+\textit{Parent Process ID}). Questi due identificativi possono essere
+ottenuti usando le due funzioni di sistema \funcd{getpid} e \funcd{getppid}, i
+cui prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
l'argomento è complesso e sarà affrontato in dettaglio in
sez.~\ref{sec:proc_perms}.
+\itindend{Process~ID~(PID)}
+\itindend{Parent~Process~ID~(PPID)}
\subsection{La funzione \func{fork} e le funzioni di creazione dei processi}
\label{sec:proc_fork}
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 è 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 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 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
-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.
-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
-state modificate, e solo al momento della modifica stessa.
+dall'istruzione successiva alla \func{fork}. Il processo figlio è una copia
+del padre, e riceve una copia dei segmenti di testo, dati e dello
+\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 e non
+condivisa, pertanto padre e figlio vedranno variabili diverse e le eventuali
+modifiche saranno totalmente indipendenti.
+
+\itindbeg{copy~on~write}
+
+Per quanto riguarda la gestione della memoria, in generale il segmento di
+testo, che è identico per i due processi, è condiviso e tenuto in sola lettura
+per il padre e per i figli. Per gli altri segmenti Linux utilizza la tecnica
+del \textit{copy on 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. 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 state modificate, e solo al momento della modifica stessa.
+
+\itindend{copy~on~write}
La differenza che si ha nei due processi è che nel processo padre il valore di
ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre
istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno
essere messi in esecuzione. Se è necessaria una qualche forma di precedenza
occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il
-rischio di incorrere nelle cosiddette \itindex{race~condition} \textit{race
- condition} (vedi sez.~\ref{sec:proc_race_cond}).
+rischio di incorrere nelle cosiddette \textit{race condition} (vedi
+sez.~\ref{sec:proc_race_cond}).
In realtà con l'introduzione dei kernel della serie 2.6 lo \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.
+meccanismo del \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
+\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
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.
+che comporta che padre e figli condividono le stesse voci della \textit{file
+ table} (tratteremo in dettaglio questi termini in sez.~\ref{sec:file_fd} e
+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
-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.
+corrente sulla \textit{file table}, e tutti gli altri processi, che vedono la
+stessa \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
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textsl{group-ID supplementari} (vedi
sez.~\ref{sec:proc_access_id});
-\item gli identificatori per il controllo di sessione: il
- \itindex{process~group} \textit{process group-ID} e il \textit{session id}
- ed il terminale di controllo (vedi sez.~\ref{sec:sess_proc_group});
-\item la \index{directory~di~lavoro} directory di lavoro e la directory radice
- (vedi sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item gli identificatori per il controllo di sessione: il \textit{process
+ group-ID} e il \textit{session id} ed il terminale di controllo (vedi
+ sez.~\ref{sec:sess_proc_group});
+\item la directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la
+ directory radice (vedi 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
\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});
-\item il valori di \textit{nice}, le priorità real-time e le affinità di
- processore (vedi sez.~\ref{sec:proc_sched_stand},
+\item il valori di \textit{nice}, le priorità \textit{real-time} e le affinità
+ di 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
\func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione
venne introdotta in BSD per migliorare le prestazioni.
-Dato che Linux supporta il \itindex{copy~on~write} \textit{copy on write} la
-perdita di prestazioni è assolutamente trascurabile, e l'uso di questa
-funzione, che resta un caso speciale della \textit{system call} \func{clone}
-(che tratteremo in dettaglio in sez.~\ref{sec:process_clone}) è deprecato; per
-questo eviteremo di trattarla ulteriormente.
+Dato che Linux supporta il \textit{copy on write} la perdita di prestazioni è
+assolutamente trascurabile, e l'uso di questa funzione, che resta un caso
+speciale della \textit{system call} \func{clone} (che tratteremo in dettaglio
+in sez.~\ref{sec:process_clone}) è deprecato; per questo eviteremo di
+trattarla ulteriormente.
\subsection{La conclusione di un processo}
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 \itindex{termination~status} \textsl{stato di
- terminazione} (il cosiddetto \textit{termination status}) al processo padre.
+scelto consiste nel riportare lo \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
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.
+\itindbeg{zombie}
+
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 terminazione anche questa
-informazione, non più necessaria, verrà scartata ed il processo potrà
-considerarsi completamente concluso.
+ancora ricevuto dal padre sono chiamati \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 terminazione anche questa informazione,
+non più necessaria, verrà scartata ed il processo potrà considerarsi
+completamente concluso.
Possiamo utilizzare il nostro programma di prova per analizzare anche questa
condizione: lanciamo il comando \cmd{forktest} in \textit{background} (vedi
%$
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 \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 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
+conclusi, con lo stato di \textit{zombie} e l'indicazione che sono terminati
+(la scritta \texttt{defunct}).
+
+La possibilità di avere degli \textit{zombie} deve essere tenuta sempre
+presente quando si scrive un programma che deve essere mantenuto 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.
+\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
-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
+diviene mai uno \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 \textit{zombie}. Questi scompaiono
+quando, alla terminazione del padre dopo i secondi programmati, tutti figli
+che avevamo generato, e che erano diventati \textit{zombie}, vengono adottati
+da \cmd{init}, il quale provvede a completarne la terminazione.
+
+Si tenga presente infine che siccome gli \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}). 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.
+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.
+\itindend{zombie}
+
+
\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
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 di sistema deputate a
-questo compito; la prima è \funcd{wait} ed il suo prototipo è:
+riempire di \textit{zombie} la tabella dei processi. Tratteremo in questa
+sezione le funzioni di sistema deputate a questo compito; la prima è
+\funcd{wait} ed il suo prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
recuperato lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
-(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 \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa
-che permette di identificare qual è il figlio che è terminato.
+(come \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
+\ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che
+permette di identificare qual è il figlio che è terminato.
-\itindend{termination~status}
+\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 è
\textbf{Valore} & \textbf{Costante} &\textbf{Significato}\\
\hline
\hline
- $<-1$& -- & Attende per un figlio il cui
- \itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è uguale
- al valore assoluto di \param{pid}.\\
- $-1$&\const{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
- questa maniera senza specificare nessuna opzione
- è equivalente a \func{wait}.\\
- $ 0$&\const{WAIT\_MYPGRP}&Attende per un figlio il cui
- \itindex{process~group} \textit{process group}
- (vedi sez.~\ref{sec:sess_proc_group}) è
- uguale a quello del processo chiamante.\\
+ $<-1$& -- & Attende per un figlio il cui \textit{process
+ group} (vedi sez.~\ref{sec:sess_proc_group}) è
+ uguale al valore assoluto di \param{pid}.\\
+ $-1$&\constd{WAIT\_ANY} & Attende per un figlio qualsiasi, usata in
+ questa maniera senza specificare nessuna opzione
+ è equivalente a \func{wait}.\\
+ $ 0$&\constd{WAIT\_MYPGRP}&Attende per un figlio il cui \textit{process
+ group} (vedi sez.~\ref{sec:sess_proc_group}) è
+ uguale a quello del processo chiamante.\\
$>0$& -- & Attende per un figlio il cui \ids{PID} è uguale
al valore di \param{pid}.\\
\hline
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}) e che vengono usati principalmente per la
-gestione della terminazione dei \itindex{thread} \textit{thread} (vedi
+gestione della terminazione dei \textit{thread} (vedi
sez.~\ref{sec:thread_xxx}).
\begin{table}[!htb]
fermato ha ripreso l'esecuzione (disponibile solo a
partire dal kernel 2.6.10).\\
\hline
- \const{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
+ \constd{\_\_WCLONE}& Attende solo per i figli creati con \func{clone}
(vedi sez.~\ref{sec:process_clone}), vale a dire
processi che non emettono nessun segnale
o emettono un segnale diverso da \signal{SIGCHLD} alla
terminazione, il default è attendere soltanto i
processi figli ordinari ignorando quelli creati da
\func{clone}.\\
- \const{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato
+ \constd{\_\_WALL} & Attende per qualunque figlio, sia ordinario che creato
con \func{clone}, se specificata insieme a
\const{\_\_WCLONE} quest'ultima viene ignorata. \\
- \const{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
+ \constd{\_\_WNOTHREAD}& Non attende per i figli di altri \textit{thread}
dello stesso \textit{thread group}, questo era il
comportamento di default del kernel 2.4 che non
supportava la possibilità, divenuta il default a
\label{tab:proc_waitpid_options}
\end{table}
+\constbeg{WNOHANG}
L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della
funzione qualora nessun figlio sia uscito o non si siano verificate le altre
invece di restituire il \ids{PID} del processo (che è sempre un intero
positivo) ritornerà un valore nullo.
+\constend{WNOHANG}
+\constbeg{WUNTRACED}
+\constbeg{WCONTINUED}
+
Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono
rispettivamente di tracciare non la terminazione di un processo, ma il fatto
che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la
\signal{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
trattato in sez.~\ref{sec:sess_ctrl_term}).
+\constend{WUNTRACED}
+\constend{WCONTINUED}
+
La terminazione di un processo figlio (così come gli altri eventi osservabili
con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
di un programma e può avvenire in un qualunque momento. Per questo motivo,
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 \itindex{zombie} \textit{zombie}). Per questo la modalità più
-comune di chiamare queste funzioni è quella di utilizzarle all'interno di un
+la presenza di \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 come gestire \signal{SIGCHLD}
con i segnali in sez.~\ref{sec:sig_example}). In questo caso infatti, dato che
il segnale è generato dalla terminazione di un figlio, avremo la certezza che
interessa memorizzare lo stato si può passare un puntatore nullo. Il valore
restituito da entrambe le funzioni dipende dall'implementazione, ma
tradizionalmente gli 8 bit meno significativi sono riservati per memorizzare
-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 \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>}.}
+lo 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 \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
\textbf{Macro} & \textbf{Descrizione}\\
\hline
\hline
- \macro{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
+ \macrod{WIFEXITED}\texttt{(s)} & Condizione vera (valore non nullo) per
un processo figlio che sia terminato
normalmente. \\
- \macro{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
+ \macrod{WEXITSTATUS}\texttt{(s)} & Restituisce gli otto bit meno
significativi dello stato di uscita del
processo (passato attraverso
\func{\_exit}, \func{exit} o come valore
di ritorno di \code{main}); può essere
valutata solo se \val{WIFEXITED} ha
restituito un valore non nullo.\\
- \macro{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
+ \macrod{WIFSIGNALED}\texttt{(s)} & Condizione vera se il processo figlio è
terminato in maniera anomala a causa di
un segnale che non è stato catturato
(vedi sez.~\ref{sec:sig_notification}).\\
- \macro{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ \macrod{WTERMSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
causato la terminazione anomala del
processo; può essere valutata solo se
\val{WIFSIGNALED} ha restituito un
valore non nullo.\\
- \macro{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
+ \macrod{WCOREDUMP}\texttt{(s)} & Vera se il processo terminato ha
generato un file di
\textit{core dump}; può essere valutata
solo se \val{WIFSIGNALED} ha restituito
un valore non nullo.\footnotemark \\
- \macro{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
+ \macrod{WIFSTOPPED}\texttt{(s)} & Vera se il processo che ha causato il
ritorno di \func{waitpid} è bloccato;
l'uso è possibile solo con
\func{waitpid} avendo specificato
l'opzione \const{WUNTRACED}.\\
- \macro{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
+ \macrod{WSTOPSIG}\texttt{(s)} & Restituisce il numero del segnale che ha
bloccato il processo; può essere
valutata solo se \val{WIFSTOPPED} ha
restituito un valore non nullo. \\
- \macro{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
+ \macrod{WIFCONTINUED}\texttt{(s)}& Vera se il processo che ha causato il
ritorno è stato riavviato da un
\signal{SIGCONT} (disponibile solo a
partire dal kernel 2.6.10).\\
\textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
- \const{P\_PID} & Indica la richiesta di attendere per un processo figlio
- il cui \ids{PID} corrisponda al valore dell'argomento
- \param{id}.\\
- \const{P\_PGID}& Indica la richiesta di attendere per un processo figlio
- appartenente al \textit{process group} (vedi
- sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
- corrisponda al valore dell'argomento \param{id}.\\
- \const{P\_ALL} & Indica la richiesta di attendere per un processo figlio
- generico, il valore dell'argomento \param{id} viene
- ignorato.\\
+ \constd{P\_PID} & Indica la richiesta di attendere per un processo figlio
+ il cui \ids{PID} corrisponda al valore dell'argomento
+ \param{id}.\\
+ \constd{P\_PGID}& Indica la richiesta di attendere per un processo figlio
+ appartenente al \textit{process group} (vedi
+ sez.~\ref{sec:sess_proc_group}) il cui \acr{pgid}
+ corrisponda al valore dell'argomento \param{id}.\\
+ \constd{P\_ALL} & Indica la richiesta di attendere per un processo figlio
+ generico, il valore dell'argomento \param{id} viene
+ ignorato.\\
\hline
\end{tabular}
\caption{Costanti per i valori dell'argomento \param{idtype} della funzione
\textbf{Valore} & \textbf{Descrizione}\\
\hline
\hline
- \const{WEXITED} & Ritorna quando un processo figlio è terminato.\\
- \const{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
- notificare.\\
- \const{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
- \const{WCONTINUED}& Ritorna quando un processo figlio che era stato
- fermato ha ripreso l'esecuzione.\\
- \const{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
- che una successiva chiamata possa di nuovo riceverne
- lo stato.\\
+ \constd{WEXITED} & Ritorna quando un processo figlio è terminato.\\
+ \constd{WNOHANG} & Ritorna immediatamente anche se non c'è niente da
+ notificare.\\
+ \constd{WSTOPPED} & Ritorna quando un processo figlio è stato fermato.\\
+ \const{WCONTINUED} & Ritorna quando un processo figlio che era stato
+ fermato ha ripreso l'esecuzione.\\
+ \constd{WNOWAIT} & Lascia il processo ancora in attesa di ricezione, così
+ che una successiva chiamata possa di nuovo riceverne
+ lo stato.\\
\hline
\end{tabular}
\caption{Costanti che identificano i bit dell'argomento \param{options}
suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui
basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti
campi:
-\begin{basedescript}{\desclabelwidth{2.0cm}}
+\begin{basedescript}{\desclabelwidth{1.8cm}}
\item[\var{si\_pid}] con il \ids{PID} del figlio.
\item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi
sez.~\ref{sec:proc_perms}) del figlio.
processo chiama una di queste funzioni esso viene completamente sostituito dal
nuovo programma, il \ids{PID} del processo non cambia, dato che non viene
creato un nuovo processo, la funzione semplicemente rimpiazza lo
-\itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il
-\index{segmento!testo} testo del processo corrente con un nuovo programma
-letto da disco, eseguendo il \itindex{link-loader} \textit{link-loader} con
-gli effetti illustrati in sez.~\ref{sec:proc_main}.
+\textit{stack}, i dati ed il testo del processo corrente con un nuovo
+programma letto da disco, eseguendo il \textit{link-loader} con gli effetti
+illustrati in sez.~\ref{sec:proc_main}.
Ci sono sei diverse versioni di \func{exec} (per questo la si è chiamata
famiglia di funzioni) che possono essere usate per questo compito, in realtà
\cmd{noexec}, o manca il permesso di attraversamento di una delle
directory del \textit{pathname}.
\item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
- \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+ \const{PT\_INTERP}, cioè chiede di essere eseguito da più di un
interprete.
\item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
riconoscibile.
riconosciuto come tale, o compilato per un'altra architettura.
\item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
- \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene
- tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}.
+ \item[\errcode{EPERM}] il file ha i bit \acr{suid} o \acr{sgid} e l'utente
+ non è root, ed il processo viene tracciato, oppure il filesystem è montato
+ con l'opzione \cmd{nosuid}.
\item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
processi.
\item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
(\ids{PPID});
\item l'\textsl{user-ID reale}, il \textsl{group-ID reale} ed i
\textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
-\item la directory radice e la \index{directory~di~lavoro} directory di lavoro
- corrente (vedi sez.~\ref{sec:file_work_dir});
-\item la maschera di creazione dei file \itindex{umask} (\textit{umask}, vedi
+\item la directory radice (vedi sez.~\ref{sec:file_chroot}) e la directory di
+ lavoro corrente (vedi sez.~\ref{sec:file_work_dir});
+\item la maschera di creazione dei file (\textit{umask}, vedi
sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
\item il valori di \textit{nice}, le priorità real-time e le affinità di
processore (vedi sez.~\ref{sec:proc_sched_stand};
sez.~\ref{sec:proc_real_time} e sez.~\ref{sec:proc_sched_multiprocess});
-\item il \textit{session ID} (\acr{sid}) ed il \itindex{process~group}
- \textit{process group ID} (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
+\item il \textit{session ID} (\acr{sid}) ed il \textit{process group ID}
+ (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
\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 \itindex{memory~locking} \textit{memory lock} (vedi
- sez.~\ref{sec:proc_mem_lock});
+\item i \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});
relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
\item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
- \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi
- sez.~\ref{sec:proc_access_id});
+ \acr{suid} o \acr{sgid} (vedi sez.~\ref{sec:proc_access_id} e
+ sez.~\ref{sec:file_special_perm});
\item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
sez.~\ref{sec:process_prctl}) viene cancellato;
\item il nome del processo viene impostato al nome del file contenente il
\itindend{close-on-exec}
-
Il comportamento della funzione in relazione agli identificatori relativi al
controllo di accesso verrà trattato in dettaglio in sez.~\ref{sec:proc_perms},
qui è sufficiente anticipare (si faccia riferimento a
stessi, mentre l'\textsl{user-ID salvato} ed il \textsl{group-ID salvato}
vengono impostati rispettivamente all'\textsl{user-ID effettivo} ed il
\textsl{group-ID effettivo}. Questi ultimi normalmente non vengono modificati,
-a meno che il file di cui viene chiesta l'esecuzione non abbia o il
-\itindex{suid~bit} \acr{suid} bit o lo \itindex{sgid~bit} \acr{sgid} bit
-impostato, in questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID
- effettivo} vengono impostati rispettivamente all'utente o al gruppo cui il
-file appartiene.
+a meno che il file di cui viene chiesta l'esecuzione non abbia o il \acr{suid}
+bit o lo \acr{sgid} bit impostato (vedi sez.~\ref{sec:file_special_perm}), in
+questo caso l'\textsl{user-ID effettivo} ed il \textsl{group-ID effettivo}
+vengono impostati rispettivamente all'utente o al gruppo cui il file
+appartiene.
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
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
+indicato nel segmento \constd{PT\_INTERP} previsto dal formato stesso, in
+genere questo è \sysfiled{/lib/ld-linux.so.1} per programmi collegati con la
+\acr{libc5}, e \sysfiled{/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
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
+\errval{ENAMETOOLONG}; una comparazione dei vari comportamenti sui diversi
sistemi unix-like si trova su
\url{http://www.in-ulm.de/~mascheck/various/shebang/}.
accesso.
Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due
-identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID}
-(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(PID)} \textsl{Group-ID}
+identificatori univoci, lo \itindex{User~ID~(UID)} \textsl{User-ID}
+(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(GID)} \textsl{Group-ID}
(abbreviato in \ids{GID}). Questi servono al kernel per identificare uno
specifico utente o un gruppo di utenti, per poi poter controllare che essi
siano autorizzati a compiere le operazioni richieste. Ad esempio in
Questi identificatori normalmente sono identici ai corrispondenti del gruppo
\textit{real} tranne nel caso in cui, come accennato in
sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
-bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
-(il significato di questi bit è affrontato in dettaglio in
-sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
-all'utente e al gruppo proprietari del file. Questo consente, per programmi in
-cui ci sia questa necessità, di dare a qualunque utente i privilegi o i
-permessi di un altro, compreso l'amministratore.
+bit \acr{suid} o \acr{sgid} impostati (il significato di questi bit è
+affrontato in dettaglio in sez.~\ref{sec:file_special_perm}). In questo caso
+essi saranno impostati all'utente e al gruppo proprietari del file. Questo
+consente, per programmi in cui ci sia questa necessità, di dare a qualunque
+utente i privilegi o i permessi di un altro, compreso l'amministratore.
Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi
identificatori possono essere ottenuti da un programma attraverso altrettante
Questo in Linux viene fatto usando altri due gruppi di identificatori, il
\textit{saved} ed il \textit{filesystem}. Il primo gruppo è lo stesso usato in
-SVr4, e previsto dallo standard POSIX quando è definita la costante
+SVr4, e previsto dallo standard POSIX quando è definita
\macro{\_POSIX\_SAVED\_IDS},\footnote{in caso si abbia a cuore la portabilità
del programma su altri Unix è buona norma controllare sempre la
disponibilità di queste funzioni controllando se questa costante è
processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del
processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID}
\textsl{effettivo} dopo che questi sono stati impostati tenendo conto di
-eventuali \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi
-quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi
-all'inizio dell'esecuzione di un nuovo programma.
+eventuali permessi \acr{suid} o \acr{sgid} (su cui torneremo in
+sez.~\ref{sec:file_special_perm}). Essi quindi consentono di tenere traccia
+di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un
+nuovo programma.
L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono
un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS
altri casi viene segnalato un errore con \errcode{EPERM}.
Come accennato l'uso principale di queste funzioni è quello di poter
-consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
-\itindex{sgid~bit} \acr{sgid} impostati (vedi
+consentire ad un programma con i bit \acr{suid} o \acr{sgid} impostati (vedi
sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello
dell'utente che ha lanciato il programma, effettuare il lavoro che non
necessita di privilegi aggiuntivi, ed eventualmente tornare indietro.
Come esempio per chiarire l'uso di queste funzioni prendiamo quello con cui
-viene gestito l'accesso al file \sysfile{/var/run/utmp}. In questo file viene
+viene gestito l'accesso al file \sysfiled{/var/run/utmp}. In questo file viene
registrato chi sta usando il sistema al momento corrente; chiaramente non può
essere lasciato aperto in scrittura a qualunque utente, che potrebbe
falsificare la registrazione. Per questo motivo questo file (e l'analogo
-\sysfile{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
+\sysfiled{/var/log/wtmp} su cui vengono registrati login e logout) appartengono
ad un gruppo dedicato (in genere \acr{utmp}) ed i programmi che devono
accedervi (ad esempio tutti i programmi di terminale in X, o il programma
\cmd{screen} che crea terminali multipli su una console) appartengono a questo
Anche queste funzioni sono un'estensione specifica di Linux, e non richiedono
nessun privilegio. I valori sono restituiti negli argomenti, che vanno
-specificati come puntatori (è un altro esempio di
-\itindex{value~result~argument} \textit{value result argument}). Si noti che
-queste funzioni sono le uniche in grado di leggere gli identificatori del
-gruppo \textit{saved}.
+specificati come puntatori (è un altro esempio di \textit{value result
+ argument}). Si noti che queste funzioni sono le uniche in grado di leggere
+gli identificatori del gruppo \textit{saved}.
Infine le funzioni \func{setfsuid} e \func{setfsgid} servono per impostare gli
identificatori del gruppo \textit{filesystem} che sono usati da Linux per il
originari per quanto riguarda tutti gli altri controlli di accesso, così che
l'utente non possa inviare segnali al server NFS.
-Le due funzioni di sistema usate per cambiare questi identificatori sono
-\funcd{setfsuid} e \funcd{setfsgid}, ed ovviamente sono specifiche di Linux e
-non devono essere usate se si intendono scrivere programmi portabili; i loro
-prototipi sono:
+Le due funzioni di sistema usate appositamente per cambiare questi
+identificatori sono \funcd{setfsuid} e \funcd{setfsgid} ovviamente sono
+specifiche di Linux e non devono essere usate se si intendono scrivere
+programmi portabili; i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/fsuid.h}
almeno \const{NGROUPS\_MAX} gruppi supplementari\footnote{il numero massimo di
gruppi secondari può essere ottenuto con \func{sysconf} (vedi
sez.~\ref{sec:sys_limits}), leggendo il parametro
- \texttt{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
+ \const{\_SC\_NGROUPS\_MAX}.} in aggiunta al gruppo primario; questi vengono
ereditati dal processo padre e possono essere cambiati con queste funzioni.
La funzione di sistema che permette di leggere i gruppi supplementari
l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei
\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups},
che in ingresso deve indicare la dimensione di \param{group}, è passato come
-\itindex{value~result~argument} \textit{value result argument} perché, qualora
-il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando
-comunque indietro il numero dei gruppi trovati, in modo da poter ripetere la
-chiamata con un vettore di dimensioni adeguate.
+\textit{value result argument} perché, qualora il valore specificato sia
+troppo piccolo, la funzione ritorna $-1$, passando comunque indietro il numero
+dei gruppi trovati, in modo da poter ripetere la chiamata con un vettore di
+dimensioni adeguate.
Infine per impostare i gruppi supplementari di un processo ci sono due
funzioni, che possono essere usate solo se si hanno i privilegi di
amministratore.\footnote{e più precisamente se si ha la \textit{capability}
- \macro{CAP\_SETGID}.} La prima delle due è la funzione di sistema
+ \const{CAP\_SETGID}.} La prima delle due è la funzione di sistema
\funcd{setgroups},\footnote{la funzione è definita in BSD e SRv4, ma a
differenza di \func{getgroups} non è stata inclusa in POSIX.1-2001, per
poterla utilizzare deve essere definita la macro \macro{\_BSD\_SOURCE}.} ed
La funzione esegue la scansione del database dei gruppi (usualmente
\conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user}
(di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una
-lista di gruppi supplementari, a cui aggiunge anche
-\param{group}, infine imposta questa lista per il processo corrente usando
-\func{setgroups}. Si tenga presente che sia \func{setgroups} che
-\func{initgroups} non sono definite nello standard POSIX.1 e che pertanto non
-è possibile utilizzarle quando si definisce \macro{\_POSIX\_SOURCE} o si
-compila con il flag \cmd{-ansi}, è pertanto meglio evitarle se si vuole
-scrivere codice portabile.
+lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine
+imposta questa lista per il processo corrente usando \func{setgroups}. Si
+tenga presente che sia \func{setgroups} che \func{initgroups} non sono
+definite nello standard POSIX.1 e che pertanto non è possibile utilizzarle
+quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
+\cmd{-ansi}, è pertanto meglio evitarle se si vuole scrivere codice portabile.
\section{La gestione della priorità dei processi}
interrotto in nessuna circostanza.\\
\textit{stopped} & \texttt{T} & Il processo è stato fermato con un
\signal{SIGSTOP}, o è tracciato.\\
- \textit{zombie}\itindex{zombie}& \texttt{Z} & Il processo è terminato ma il
+ \textit{zombie} & \texttt{Z} & Il processo è terminato ma il
suo stato di terminazione non è ancora
stato letto dal padre.\\
\textit{killable}& \texttt{D} & Un nuovo stato introdotto con il kernel
\end{errlist}}
\end{funcproto}
+\constbeg{PRIO\_MIN}
+\constbeg{PRIO\_MAX}
+
L'argomento \param{inc} indica l'incremento da effettuare rispetto al valore
di \textit{nice} corrente, che può assumere valori compresi fra
\const{PRIO\_MIN} e \const{PRIO\_MAX}; nel caso di Linux sono fra $-20$ e
utenti normali alzare (entro certi limiti, che vedremo in
sez.~\ref{sec:sys_resource_limit}) la priorità dei propri processi.
+\constend{PRIO\_MIN}
+\constend{PRIO\_MAX}
+
Gli standard SUSv2 e POSIX.1 prevedono che la funzione ritorni il nuovo valore
di \textit{nice} del processo; tuttavia la \textit{system call} di Linux non
segue questa convenzione e restituisce sempre $0$ in caso di successo e $-1$
nell'argomento \param{which}, di leggere il valore di \textit{nice} di un
processo, di un gruppo di processi (vedi sez.~\ref{sec:sess_proc_group}) o di
un utente indicato dall'argomento \param{who}. Nelle vecchie versioni può
-essere necessario includere anche \headfile{sys/time.h}, questo non è più
+essere necessario includere anche \headfiled{sys/time.h}, questo non è più
necessario con versioni recenti delle librerie, ma è comunque utile per
portabilità.
\param{which} & \param{who} & \textbf{Significato} \\
\hline
\hline
- \const{PRIO\_PROCESS} & \type{pid\_t} & processo \\
- \const{PRIO\_PRGR} & \type{pid\_t} & \itindex{process~group}
- \textit{process group}\\
- \const{PRIO\_USER} & \type{uid\_t} & utente \\
+ \constd{PRIO\_PROCESS} & \type{pid\_t} & processo \\
+ \constd{PRIO\_PRGR} & \type{pid\_t} & \textit{process group} (vedi
+ sez.~\ref{sec:sess_proc_group})\\
+ \constd{PRIO\_USER} & \type{uid\_t} & utente \\
\hline
\end{tabular}
\caption{Legenda del valore dell'argomento \param{which} e del tipo
\textit{real-time} (o nel caso di Adeos gestiti dalle code del nano-kernel),
in modo da poterli controllare direttamente qualora ci sia la necessità di
avere un processo con priorità più elevata di un \textit{interrupt
- handler}.} mentre con l'incorrere in un \itindex{page~fault} \textit{page
- fault} si possono avere ritardi non previsti. Se l'ultimo problema può
-essere aggirato attraverso l'uso delle funzioni di controllo della memoria
-virtuale (vedi sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può
-comportare ritardi non prevedibili riguardo ai tempi di esecuzione di
-qualunque processo.
+ handler}.} mentre con l'incorrere in un \textit{page fault} si possono
+avere ritardi non previsti. Se l'ultimo problema può essere aggirato
+attraverso l'uso delle funzioni di controllo della memoria virtuale (vedi
+sez.~\ref{sec:proc_mem_lock}), il primo non è superabile e può comportare
+ritardi non prevedibili riguardo ai tempi di esecuzione di qualunque processo.
Nonostante questo, ed in particolare con una serie di miglioramenti che sono
stati introdotti nello sviluppo del kernel,\footnote{in particolare a partire
\textbf{Politica} & \textbf{Significato} \\
\hline
\hline
- \const{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
- \textit{FIFO}. \\
- \const{SCHED\_RR} & \textit{Scheduling real-time} con politica
- \textit{Round Robin}. \\
+ \constd{SCHED\_FIFO} & \textit{Scheduling real-time} con politica
+ \textit{FIFO}. \\
+ \constd{SCHED\_RR} & \textit{Scheduling real-time} con politica
+ \textit{Round Robin}. \\
\hline
- \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).\\
- \const{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
- bassa (dal kernel 2.6.23).\\
+ \constd{SCHED\_OTHER}& \textit{Scheduling} ordinario.\\
+ \constd{SCHED\_BATCH}& \textit{Scheduling} ordinario con l'assunzione
+ ulteriore di lavoro \textit{CPU
+ intensive} (dal kernel 2.6.16).\\
+ \constd{SCHED\_IDLE} & \textit{Scheduling} di priorità estremamente
+ bassa (dal kernel 2.6.23).\\
\hline
\end{tabular}
\caption{Valori dell'argomento \param{policy} per la funzione
la priorità dinamica determinata dal valore di \textit{nice}, che deve essere
impostato con le funzioni viste in precedenza.
-Lo standard POSIX.1b prevede inoltre che l'intervallo dei valori delle
-priorità statiche possa essere ottenuto con le funzioni di sistema
+Lo standard POSIX.1b prevede 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:
che per i primi la priorità statica può essere soltanto nulla. La
disponibilità di entrambe le funzioni può essere verificata controllando la
macro \macro{\_POSIX\_PRIORITY\_SCHEDULING} che è definita nell'\textit{header
- file} \headfile{sched.h}.
+ file} \headfiled{sched.h}.
Se invece si vuole sapere quale è politica di \textit{scheduling} di un
processo si può usare la funzione di sistema \funcd{sched\_getscheduler}, il
cambiato ed un processo che chiama la funzione viene inserito nella lista dei
processi inattivo, con un tempo molto maggiore.\footnote{è comunque possibile
ripristinare un comportamento analogo al precedente scrivendo il valore 1
- nel file \sysctlfile{kernel/sched\_compat\_yield}.}
+ nel file \sysctlfiled{kernel/sched\_compat\_yield}.}
L'uso delle funzione nella programmazione ordinaria può essere utile e
migliorare le prestazioni generali del sistema quando si è appena rilasciata
possibilità di approfittarne mettendoli in esecuzione, ma chiamarla senza
necessità, specie se questo avviene ripetutamente all'interno di un qualche
ciclo, può avere invece un forte impatto negativo per la generazione di
-\itindex{contest~switch} \textit{contest switch} inutili.
+\textit{context switch} inutili.
\subsection{Il controllo dello \textit{scheduler} per i sistemi
multiprocessore}
\label{sec:proc_sched_multiprocess}
+\index{effetto~ping-pong|(}
+
Con il supporto dei sistemi multiprocessore sono state introdotte delle
funzioni che permettono di controllare in maniera più dettagliata la scelta di
quale processore utilizzare per eseguire un certo programma. Uno dei problemi
che si pongono nei sistemi multiprocessore è infatti quello del cosiddetto
-\index{effetto~ping-pong} \textsl{effetto ping-pong}. Può accadere cioè che lo
-\textit{scheduler}, quando riavvia un processo precedentemente interrotto
-scegliendo il primo processore disponibile, lo faccia eseguire da un
-processore diverso rispetto a quello su cui era stato eseguito in
-precedenza. Se il processo passa da un processore all'altro in questo modo,
-cosa che avveniva abbastanza di frequente con i kernel della seria 2.4.x, si
-ha l'\textsl{effetto ping-pong}.
+\textsl{effetto ping-pong}. Può accadere cioè che lo \textit{scheduler},
+quando riavvia un processo precedentemente interrotto scegliendo il primo
+processore disponibile, lo faccia eseguire da un processore diverso rispetto a
+quello su cui era stato eseguito in precedenza. Se il processo passa da un
+processore all'altro in questo modo, cosa che avveniva abbastanza di frequente
+con i kernel della seria 2.4.x, si ha l'effetto ping-pong.
Questo tipo di comportamento può generare dei seri problemi di prestazioni;
infatti tutti i processori moderni utilizzano una memoria interna (la
Questo comporta che quando un processore inserisce un dato nella sua cache,
tutti gli altri processori che hanno lo stesso dato devono invalidarlo, e
questa operazione è molto costosa in termini di prestazioni. Il problema
-diventa serio quando si verifica l'\textsl{effetto ping-pong}, in tal caso
-infatti un processo \textsl{rimbalza} continuamente da un processore all'altro
-e si ha una continua invalidazione della cache, che non diventa mai
-disponibile.
+diventa serio quando si verifica l'effetto ping-pong, in tal caso infatti un
+processo \textsl{rimbalza} continuamente da un processore all'altro e si ha
+una continua invalidazione della cache, che non diventa mai disponibile.
\itindbeg{CPU~affinity}
di processore} (o \textit{CPU affinity}); la possibilità cioè di far sì che
un processo possa essere assegnato per l'esecuzione sempre allo stesso
processore. Lo \textit{scheduler} dei kernel della serie 2.4.x aveva una
-scarsa \textit{CPU affinity}, e \index{effetto~ping-pong} l'effetto ping-pong
-era comune; con il nuovo \textit{scheduler} dei kernel della 2.6.x questo
-problema è stato risolto ed esso cerca di mantenere il più possibile ciascun
-processo sullo stesso processore.
+scarsa \textit{CPU affinity}, e l'effetto ping-pong era comune; con il nuovo
+\textit{scheduler} dei kernel della 2.6.x questo problema è stato risolto ed
+esso cerca di mantenere il più possibile ciascun processo sullo stesso
+processore.
+
+\index{effetto~ping-pong|)}
In certi casi però resta l'esigenza di poter essere sicuri che un processo sia
sempre eseguito dallo stesso processore,\footnote{quella che viene detta
(\textit{Non-Uniform Memory Access}).
Infine se un gruppo di processi accede alle stesse risorse condivise (ad
-esempio una applicazione con più \itindex{thread} \textit{thread}) può avere
-senso usare lo stesso processore in modo da sfruttare meglio l'uso della sua
-cache; questo ovviamente riduce i benefici di un sistema multiprocessore
-nell'esecuzione contemporanea dei \itindex{thread} \textit{thread}, ma in
-certi casi (quando i \itindex{thread} \textit{thread} sono inerentemente
-serializzati nell'accesso ad una risorsa) possono esserci sufficienti vantaggi
-nell'evitare la perdita della cache da rendere conveniente l'uso dell'affinità
-di processore.
+esempio una applicazione con più \textit{thread}) può avere senso usare lo
+stesso processore in modo da sfruttare meglio l'uso della sua cache; questo
+ovviamente riduce i benefici di un sistema multiprocessore nell'esecuzione
+contemporanea dei \textit{thread}, ma in certi casi (quando i \textit{thread}
+sono inerentemente serializzati nell'accesso ad una risorsa) possono esserci
+sufficienti vantaggi nell'evitare la perdita della cache da rendere
+conveniente l'uso dell'affinità di processore.
Dato che il numero di processori può variare a seconda delle architetture, per
semplificare l'uso dell'argomento \param{mask} la \acr{glibc} ha introdotto un
-apposito dato di tipo, \type{cpu\_set\_t},\footnote{questa è una estensione
+apposito dato di tipo, \typed{cpu\_set\_t},\footnote{questa è una estensione
specifica della \acr{glibc}, da attivare definendo la macro
\macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo
tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che
maschera binaria: nei casi più comuni potrebbe bastare un intero a 32 bit, in
cui ogni bit corrisponde ad un processore, ma oggi esistono architetture in
cui questo numero può non essere sufficiente, e per questo è stato creato
-questo \index{tipo!opaco} tipo opaco e una interfaccia di gestione che
-permette di usare a basso livello un tipo di dato qualunque rendendosi
-indipendenti dal numero di bit e dalla loro disposizione. Per questo le
-funzioni richiedono anche che oltre all'insieme di processori si indichi anche
-la dimensione dello stesso con l'argomento \param{setsize}, per il quale, se
-non si usa l'allocazione dinamica che vedremo a breve, ed è in genere
-sufficiente passare il valore \code{sizeof(cpu\_set\_t)}.
+questo tipo opaco e una interfaccia di gestione che permette di usare a basso
+livello un tipo di dato qualunque rendendosi indipendenti dal numero di bit e
+dalla loro disposizione. Per questo le funzioni richiedono anche che oltre
+all'insieme di processori si indichi anche la dimensione dello stesso con
+l'argomento \param{setsize}, per il quale, se non si usa l'allocazione
+dinamica che vedremo a breve, ed è in genere sufficiente passare il valore
+\code{sizeof(cpu\_set\_t)}.
L'interfaccia di gestione degli insiemi di processori, oltre alla definizione
del tipo \type{cpu\_set\_t}, prevede una serie di macro di preprocessore per
\vspace{3pt}
\begin{funcbox}{
\fhead{sched.h}
-\fdecl{void \macro{CPU\_ZERO}(cpu\_set\_t *set)}
+\fdecl{void \macrod{CPU\_ZERO}(cpu\_set\_t *set)}
\fdesc{Inizializza un insieme di processori vuoto \param{set}.}
-\fdecl{void \macro{CPU\_SET}(int cpu, cpu\_set\_t *set)}
-\fdesc{Inserisce il processore \param{cpu} nell'insieme di processori \param{set}.}
-\fdecl{void \macro{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
-\fdesc{Rimuove il processore \param{cpu} nell'insieme di processori \param{set}.}
-\fdecl{int \macro{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
-\fdesc{Controlla se il processore \param{cpu} è nell'insieme di processori \param{set}.}
+\fdecl{void \macrod{CPU\_SET}(int cpu, cpu\_set\_t *set)}
+\fdesc{Inserisce il processore \param{cpu} nell'insieme di
+ processori \param{set}.}
+\fdecl{void \macrod{CPU\_CLR}(int cpu, cpu\_set\_t *set)}
+\fdesc{Rimuove il processore \param{cpu} nell'insieme di
+ processori \param{set}.}
+\fdecl{int \macrod{CPU\_ISSET}(int cpu, cpu\_set\_t *set)}
+\fdesc{Controlla se il processore \param{cpu} è nell'insieme di
+ processori \param{set}.}
}
\end{funcbox}}
restituisce un intero da usare come valore logico (zero se la CPU non è
presente, diverso da zero se è presente).
+\itindbeg{side~effects}
Si tenga presente che trattandosi di macro l'argomento \param{cpu} può essere
valutato più volte. Questo significa ad esempio che non si può usare al suo
posto una funzione o un'altra macro, altrimenti queste verrebbero eseguite più
volte, l'argomento cioè non deve avere \textsl{effetti collaterali} (in gergo
-\itindex{side~effects} \textit{side effects}).\footnote{nel linguaggio C si
+ \textit{side effects}).\footnote{nel linguaggio C si
parla appunto di \textit{side effects} quando si usano istruzioni la cui
valutazione comporta effetti al di fuori dell'istruzione stessa, come il
caso indicato in cui si passa una funzione ad una macro che usa l'argomento
al suo interno più volte, o si scrivono espressioni come \code{a=a++} in cui
non è chiaro se prima avvenga l'incremento e poi l'assegnazione, ed il cui
risultato dipende dall'implementazione del compilatore.}
+\itindend{side~effects}
+
Le CPU sono numerate da zero (che indica la prima disponibile) fino ad
un numero massimo che dipende dalla architettura hardware. La costante
-\const{CPU\_SETSIZE} indica il numero massimo di processori che possono far
+\constd{CPU\_SETSIZE} indica il numero massimo di processori che possono far
parte di un insieme (al momento vale sempre 1024), e costituisce un limite
massimo al valore dell'argomento \param{cpu}.
Dalla versione 2.6 della \acr{glibc} alle precedenti macro è stata aggiunta,
\vspace{3pt}
\begin{funcbox}{
\fhead{sched.h}
-\fdecl{int \macro{CPU\_COUNT}(cpu\_set\_t *set)}
+\fdecl{int \macrod{CPU\_COUNT}(cpu\_set\_t *set)}
\fdesc{Conta il numero di processori presenti nell'insieme \param{set}.}
}
\end{funcbox}}
\vspace{3pt}
\begin{funcbox}{
\fhead{sched.h}
-\fdecl{void \macro{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdecl{void \macrod{CPU\_AND}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
\fdesc{Esegue l'AND logico di due insiemi di processori.}
-\fdecl{void \macro{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdecl{void \macrod{CPU\_OR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
\fdesc{Esegue l'OR logico di due insiemi di processori.}
-\fdecl{void \macro{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
+\fdecl{void \macrod{CPU\_XOR}(cpu\_set\_t *destset, cpu\_set\_t *srcset1, cpu\_set\_t *srcset2)}
\fdesc{Esegue lo XOR logico di due insiemi di processori.}
-\fdecl{int \macro{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
+\fdecl{int \macrod{CPU\_EQUAL}(cpu\_set\_t *set1, cpu\_set\_t *set2)}
\fdesc{Verifica se due insiemi di processori sono uguali.}
}
\end{funcbox}}
\vspace{3pt}
\begin{funcbox}{
\fhead{sched.h}
-\fdecl{cpu\_set\_t * \macro{CPU\_ALLOC}(num\_cpus)}
+\fdecl{cpu\_set\_t * \macrod{CPU\_ALLOC}(num\_cpus)}
\fdesc{Alloca dinamicamente un insieme di processori di dimensione voluta.}
-\fdecl{void \macro{CPU\_FREE}(cpu\_set\_t *set)}
+\fdecl{void \macrod{CPU\_FREE}(cpu\_set\_t *set)}
\fdesc{Disalloca un insieme di processori allocato dinamicamente.}
-\fdecl{size\_t \macro{CPU\_ALLOC\_SIZE}(num\_cpus)}
+\fdecl{size\_t \macrod{CPU\_ALLOC\_SIZE}(num\_cpus)}
\fdesc{Ritorna la dimensione di un insieme di processori allocato dinamicamente.}
}
\end{funcbox}}
\param{which} & \param{who} & \textbf{Significato} \\
\hline
\hline
- \const{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
- \const{IPRIO\_WHO\_PRGR} & \type{pid\_t} & \itindex{process~group}
- \textit{process group}\\
- \const{IPRIO\_WHO\_USER} & \type{uid\_t} & utente\\
+ \constd{IPRIO\_WHO\_PROCESS} & \type{pid\_t} & processo\\
+ \constd{IPRIO\_WHO\_PRGR} & \type{pid\_t} & \textit{process group}\\
+ \constd{IPRIO\_WHO\_USER} & \type{uid\_t} & utente\\
\hline
\end{tabular}
\caption{Legenda del valore dell'argomento \param{which} e del tipo
classe stessa. Questo stesso formato viene utilizzato per indicare il valore
della priorità da impostare con l'argomento \param{ioprio} di
\func{ioprio\_set}.
+
\begin{table}[htb]
\centering
\footnotesize
\textbf{Macro} & \textbf{Significato}\\
\hline
\hline
- \macro{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
+ \macrod{IOPRIO\_PRIO\_CLASS}\texttt{(\textit{value})}
& Dato il valore di una priorità come
restituito da \func{ioprio\_get} estrae il
valore della classe.\\
- \macro{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
+ \macrod{IOPRIO\_PRIO\_DATA}\texttt{(\textit{value})}
& 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})}
+ \macrod{IOPRIO\_PRIO\_VALUE}\texttt{(\textit{class},\textit{prio})}
& Dato un valore di priorità ed una classe
ottiene il valore numerico da passare a
\func{ioprio\_set}.\\
\textbf{Classe} & \textbf{Significato} \\
\hline
\hline
- \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O \textit{real-time}.\\
+ \const{IOPRIO\_CLASS\_RT} & \textit{Scheduling} di I/O
+ \textit{real-time}.\\
\const{IOPRIO\_CLASS\_BE} & \textit{Scheduling} di I/O ordinario.\\
- \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità minima.\\
+ \const{IOPRIO\_CLASS\_IDLE}& \textit{Scheduling} di I/O di priorità
+ minima.\\
\hline
\end{tabular}
\caption{Costanti che identificano le classi di \textit{scheduling} di I/O.}
processore. Ciascuna di esse è identificata tramite una opportuna costante,
secondo quanto riportato in tab.~\ref{tab:IOsched_class}.
-La classe di priorità più bassa è \const{IOPRIO\_CLASS\_IDLE}; i processi in
+La classe di priorità più bassa è \constd{IOPRIO\_CLASS\_IDLE}; i processi in
questa classe riescono ad accedere a disco soltanto quando nessun altro
processo richiede l'accesso. Occorre pertanto usarla con molta attenzione,
perché un processo in questa classe può venire completamente bloccato quando
valore di priorità, dato che in questo caso non esiste nessuna gerarchia e la
priorità è identica, la minima possibile, per tutti i processi.
-La seconda classe di priorità di I/O è \const{IOPRIO\_CLASS\_BE} (il nome sta
+La seconda classe di priorità di I/O è \constd{IOPRIO\_CLASS\_BE} (il nome sta
per \textit{best-effort}) che è quella usata ordinariamente da tutti
processi. In questo caso esistono priorità diverse che consentono di
assegnazione di una maggiore banda passante nell'accesso a disco ad un
Infine la classe di priorità di I/O \textit{real-time}
-\const{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
+\constd{IOPRIO\_CLASS\_RT} ricalca le omonime priorità di processore: un
processo in questa classe ha sempre la precedenza nell'accesso a disco
rispetto a tutti i processi delle altre classi e di un processo nella stessa
classe ma con priorità inferiore, ed è pertanto in grado di bloccare
predefinite del seguente elenco, che illustra quelle disponibili al
momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.}
-\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
+\begin{basedescript}{\desclabelwidth{1.5cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
\textit{capability} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
Introdotta a partire dal kernel 2.6.25.
-\item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
+\item[\constd{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
\textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
da tutti i suoi discendenti. La funzione cancella la capacità specificata
nell'argomento \param{arg2} con una delle costanti di
chiamata fallirà con un errore di \errval{EINVAL}. Introdotta a partire dal
kernel 2.6.25.
-\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
+\item[\constd{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
terminazione di un processo a causa di un segnale per il quale è prevista la
generazione di un file di \textit{core dump} (vedi
sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
\textit{core dump} appartenente all'amministratore in directory dove
l'utente avrebbe avuto permessi di accesso.
-\item[\const{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
+\item[\constd{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
lo stato corrente del flag che controlla la effettiva generazione dei
\textit{core dump}. Introdotta a partire dal kernel 2.3.20.
-\item[\const{PR\_SET\_ENDIAN}] Imposta la \itindex{endianness}
- \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
+\item[\constd{PR\_SET\_ENDIAN}] Imposta la \textit{endianness} del processo
+ chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
+ sono: \constd{PR\_ENDIAN\_BIG} (\textit{big endian}),
+ \constd{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
+ \constd{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 \itindex{endianness}
- \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.
+\item[\constd{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.
-\item[\const{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
+\item[\constd{PR\_SET\_FPEMU}] Imposta i bit di controllo per l'emulazione
della virgola mobile su architettura ia64, secondo il valore
- di \param{arg2}, si deve passare \const{PR\_FPEMU\_NOPRINT} per emulare in
+ di \param{arg2}, si deve passare \constd{PR\_FPEMU\_NOPRINT} per emulare in
maniera trasparente l'accesso alle operazioni in virgola mobile, o
- \const{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
+ \constd{PR\_FPEMU\_SIGFPE} per non emularle ed inviare il segnale
\signal{SIGFPE} (vedi sez.~\ref{sec:sig_prog_error}). Introdotta a partire
dal kernel 2.4.18, solo su architettura ia64.
-\item[\const{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
+\item[\constd{PR\_GET\_FPEMU}] Ottiene il valore dei flag di controllo
dell'emulazione della virgola mobile, salvato all'indirizzo puntato
da \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
partire dal kernel 2.4.18, solo su architettura ia64.
-\item[\const{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
+\item[\constd{PR\_SET\_FPEXC}] Imposta la modalità delle eccezioni in virgola
mobile (\textit{floating-point exception mode}) al valore di \param{arg2}.
I valori possibili sono:
\begin{itemize*}
- \item \const{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
- \item \const{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
- \item \const{PR\_FP\_EXC\_OVF} per gli overflow,
- \item \const{PR\_FP\_EXC\_UND} per gli underflow,
- \item \const{PR\_FP\_EXC\_RES} per risultati non esatti,
- \item \const{PR\_FP\_EXC\_INV} per operazioni invalide,
- \item \const{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
- \item \const{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
+ \item \constd{PR\_FP\_EXC\_SW\_ENABLE} per usare FPEXC per le eccezioni,
+ \item \constd{PR\_FP\_EXC\_DIV} per la divisione per zero in virgola mobile,
+ \item \constd{PR\_FP\_EXC\_OVF} per gli overflow,
+ \item \constd{PR\_FP\_EXC\_UND} per gli underflow,
+ \item \constd{PR\_FP\_EXC\_RES} per risultati non esatti,
+ \item \constd{PR\_FP\_EXC\_INV} per operazioni invalide,
+ \item \constd{PR\_FP\_EXC\_DISABLED} per disabilitare le eccezioni,
+ \item \constd{PR\_FP\_EXC\_NONRECOV} per usare la modalità di eccezione
asincrona non recuperabile,
- \item \const{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
+ \item \constd{PR\_FP\_EXC\_ASYNC} per usare la modalità di eccezione
asincrona recuperabile,
- \item \const{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
+ \item \constd{PR\_FP\_EXC\_PRECISE} per la modalità precisa di
eccezione.\footnote{trattasi di gestione specialistica della gestione
delle eccezioni dei calcoli in virgola mobile che, i cui dettagli al
momento vanno al di là dello scopo di questo testo.}
\end{itemize*}
Introdotta a partire dal kernel 2.4.21, solo su PowerPC.
-\item[\const{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
+\item[\constd{PR\_GET\_FPEXC}] Ottiene il valore della modalità delle eccezioni
delle operazioni in virgola mobile, salvata all'indirizzo
puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta
a partire dal kernel 2.4.21, solo su PowerPC.
-\item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali
+\item[\constd{PR\_SET\_KEEPCAPS}] Consente di controllare quali
\textit{capabilities} vengono cancellate quando si esegue un cambiamento di
\ids{UID} del processo (per i dettagli si veda
sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a
per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano
mantenute, questo valore viene sempre cancellato attraverso una \func{exec}.
L'uso di questo flag è stato sostituito, a partire dal kernel 2.6.26, dal
- flag \const{SECURE\_KEEP\_CAPS} dei \itindex{securebits} \textit{securebits}
- (vedi l'uso di \const{PR\_SET\_SECUREBITS} più avanti). Introdotta a partire
- dal kernel 2.2.18.
+ flag \const{SECURE\_KEEP\_CAPS} dei \textit{securebits} (vedi
+ sez.~\ref{sec:proc_capabilities} e l'uso di \const{PR\_SET\_SECUREBITS} più
+ avanti). Introdotta a partire dal kernel 2.2.18.
-\item[\const{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
+\item[\constd{PR\_GET\_KEEPCAPS}] Ottiene come valore di ritorno della funzione
il valore del flag di controllo delle \textit{capabilities} impostato con
\const{PR\_SET\_KEEPCAPS}. Introdotta a partire dal kernel 2.2.18.
-\item[\const{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
+\item[\constd{PR\_SET\_NAME}] Imposta il nome del processo chiamante alla
stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}''. Il
nome può essere lungo al massimo 16 caratteri, e la stringa deve essere
terminata da NUL se più corta. Introdotta a partire dal kernel 2.6.9.
-\item[\const{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
+\item[\constd{PR\_GET\_NAME}] Ottiene il nome del processo chiamante nella
stringa puntata da \param{arg2}, che deve essere di tipo ``\ctyp{char *}'';
si devono allocare per questo almeno 16 byte, e il nome sarà terminato da
NUL se più corto. Introdotta a partire dal kernel 2.6.9.
-\item[\const{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
+\item[\constd{PR\_SET\_PDEATHSIG}] Consente di richiedere l'emissione di un
segnale, che sarà ricevuto dal processo chiamante, in occorrenza della
terminazione del proprio processo padre; in sostanza consente di invertire
il ruolo di \signal{SIGCHLD}. Il valore di \param{arg2} deve indicare il
automaticamente cancellato per un processo figlio creato con \func{fork}.
Introdotta a partire dal kernel 2.1.57.
-\item[\const{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
+\item[\constd{PR\_GET\_PDEATHSIG}] Ottiene il valore dell'eventuale segnale
emesso alla terminazione del padre, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
partire dal kernel 2.3.15.
-\item[\const{PR\_SET\_SECCOMP}] Imposta il cosiddetto
- \itindex{secure~computing~mode} \textit{secure computing mode} per il
- processo corrente. Prevede come unica possibilità che \param{arg2} sia
- impostato ad 1. Una volta abilitato il \itindex{secure~computing~mode}
- \textit{secure computing mode} il processo potrà utilizzare soltanto un
- insieme estremamente limitato di \textit{system call}: \func{read},
- \func{write}, \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system
- call} porterà all'emissione di un \signal{SIGKILL} (vedi
- sez.~\ref{sec:sig_termination}). Il \textit{secure computing mode} è stato
- ideato per fornire un supporto per l'esecuzione di codice esterno non fidato
- e non verificabile a scopo di calcolo;\footnote{lo scopo è quello di poter
- vendere la capacità di calcolo della proprio macchina ad un qualche
- servizio di calcolo distribuito senza comprometterne la sicurezza
- eseguendo codice non sotto il proprio controllo.} in genere i dati vengono
- letti o scritti grazie ad un socket o una \textit{pipe}, e per evitare
- problemi di sicurezza non sono possibili altre operazioni se non quelle
- citate. Introdotta a partire dal kernel 2.6.23, disponibile solo se si è
- abilitato il supporto nel kernel con \texttt{CONFIG\_SECCOMP}.
+\itindbeg{secure~computing~mode}
+\item[\constd{PR\_SET\_SECCOMP}] Imposta il cosiddetto \textit{secure computing
+ mode} per il processo corrente. Prevede come unica possibilità
+ che \param{arg2} sia impostato ad 1. Una volta abilitato il \textit{secure
+ computing mode} il processo potrà utilizzare soltanto un insieme
+ estremamente limitato di \textit{system call}: \func{read}, \func{write},
+ \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system call} porterà
+ all'emissione di un \signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}).
+ Il \textit{secure computing mode} è stato ideato per fornire un supporto per
+ l'esecuzione di codice esterno non fidato e non verificabile a scopo di
+ calcolo;\footnote{lo scopo è quello di poter vendere la capacità di calcolo
+ della proprio macchina ad un qualche servizio di calcolo distribuito senza
+ comprometterne la sicurezza eseguendo codice non sotto il proprio
+ controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
+ una \textit{pipe}, e per evitare problemi di sicurezza non sono possibili
+ altre operazioni se non quelle citate. 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
% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
-\item[\const{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
+\item[\constd{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
- che la chiamata di questa funzione in \itindex{secure~computing~mode}
- \textit{secure computing mode} comporterebbe l'emissione di
- \signal{SIGKILL}, è stata comunque definita per eventuali estensioni future.
- Introdotta a partire dal kernel 2.6.23.
-
-\item[\const{PR\_SET\_SECUREBITS}] Imposta i \itindex{securebits}
- \textit{securebits} per il processo chiamante al valore indicato
- da \param{arg2}; per i dettagli sul significato dei \textit{securebits} si
- veda sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
+ che la chiamata di questa funzione in \textit{secure computing mode}
+ comporterebbe l'emissione di \signal{SIGKILL}, è stata comunque definita per
+ eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
+\itindend{secure~computing~mode}
+
+\item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
+ processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
+ significato dei \textit{securebits} si veda
+ sez.~\ref{sec:proc_capabilities}, ed in particolare i valori di
tab.~\ref{tab:securebits_values} e la relativa trattazione. L'operazione
richiede i privilegi di amministratore (la capacità \const{CAP\_SETPCAP}),
altrimenti la chiamata fallirà con un errore di \errval{EPERM}. Introdotta a
partire dal kernel 2.6.26.
-\item[\const{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
- funzione l'impostazione corrente per i \itindex{securebits}
- \textit{securebits}. Introdotta a partire dal kernel 2.6.26.
+\item[\constd{PR\_GET\_SECUREBITS}] Ottiene come valore di ritorno della
+ funzione l'impostazione corrente per i \textit{securebits}. Introdotta a
+ partire dal kernel 2.6.26.
-\item[\const{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
+\item[\constd{PR\_SET\_TIMING}] Imposta il metodo di temporizzazione del
processo da indicare con il valore di \param{arg2}, attualmente i valori
- possibili sono due, con \const{PR\_TIMING\_STATISTICAL} si usa il metodo
- statistico tradizionale, con \const{PR\_TIMING\_TIMESTAMP} il più accurato
+ possibili sono due, con \constd{PR\_TIMING\_STATISTICAL} si usa il metodo
+ statistico tradizionale, con \constd{PR\_TIMING\_TIMESTAMP} il più accurato
basato su dei \textit{timestamp}, quest'ultimo però non è ancora
implementato ed il suo uso comporta la restituzione di un errore di
\errval{EINVAL}. Introdotta a partire dal kernel 2.6.0-test4.
-\item[\const{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
+\item[\constd{PR\_GET\_TIMING}] Ottiene come valore di ritorno della funzione
il metodo di temporizzazione del processo attualmente in uso (uno dei due
valori citati per \const{PR\_SET\_TIMING}). Introdotta a partire dal kernel
2.6.0-test4.
-\item[\const{PR\_SET\_TSC}] Imposta il flag che indica se il processo
+\item[\constd{PR\_SET\_TSC}] Imposta il flag che indica se il processo
chiamante può leggere il registro di processore contenente il contatore dei
\textit{timestamp} (TSC, o \textit{Time Stamp Counter}) da indicare con il
- valore di \param{arg2}. Si deve specificare \const{PR\_TSC\_ENABLE} per
- abilitare la lettura o \const{PR\_TSC\_SIGSEGV} per disabilitarla con la
+ valore di \param{arg2}. Si deve specificare \constd{PR\_TSC\_ENABLE} per
+ abilitare la lettura o \constd{PR\_TSC\_SIGSEGV} per disabilitarla con la
generazione di un segnale di \signal{SIGSEGV} (vedi
sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
- disabilitata se si attiva il \itindex{secure~computing~mode} \textit{secure
- computing mode}. Introdotta a partire dal kernel 2.6.26, solo su x86.
+ disabilitata se si attiva il \textit{secure computing mode} (vedi
+ \const{PR\_SET\_SECCOMP} più avanti). Introdotta a partire dal kernel
+ 2.6.26, solo su x86.
-\item[\const{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
+\item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
puntato \param{arg2}, che deve essere di tipo ``\ctyp{int *}''. Introdotta a
partire dal kernel 2.6.26, solo su x86.
% http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html,
% http://en.wikipedia.org/wiki/Time_Stamp_Counter
-\item[\const{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
+\item[\constd{PR\_SET\_UNALIGN}] Imposta la modalità di controllo per l'accesso
a indirizzi di memoria non allineati, che in varie architetture risultano
illegali, da indicare con il valore di \param{arg2}. Si deve specificare il
- valore \const{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
- ed il valore \const{PR\_UNALIGN\_SIGBUS} per generare un segnale di
+ valore \constd{PR\_UNALIGN\_NOPRINT} per ignorare gli accessi non allineati,
+ ed il valore \constd{PR\_UNALIGN\_SIGBUS} per generare un segnale di
\signal{SIGBUS} (vedi sez.~\ref{sec:sig_prog_error}) in caso di accesso non
allineato. Introdotta con diverse versioni su diverse architetture.
Il comportamento di default prevede che per tutti i processi si applichi la
politica generale di sistema definita nel file
- \sysctlfile{vm/memory\_failure\_early\_kill}, ma specificando
- per \param{arg2} il valore \const{PR\_MCE\_KILL\_SET} è possibile impostare
+ \sysctlfiled{vm/memory\_failure\_early\_kill}, ma specificando
+ per \param{arg2} il valore \constd{PR\_MCE\_KILL\_SET} è possibile impostare
con il contenuto di \param{arg3} una politica specifica del processo
chiamante. Si può tornare alla politica di default del sistema utilizzando
- invece per \param{arg2} il valore \const{PR\_MCE\_KILL\_CLEAR}. In tutti i
+ invece per \param{arg2} il valore \constd{PR\_MCE\_KILL\_CLEAR}. In tutti i
casi, per compatibilità con eventuali estensioni future, tutti i valori
degli argomenti non utilizzati devono essere esplicitamente posti a zero,
pena il fallimento della chiamata con un errore di \errval{EINVAL}.
\const{PR\_MCE\_KILL\_SET} i valori di \param{arg3} possono essere soltanto
due, che corrispondono anche al valore che si trova nell'impostazione
generale di sistema di \texttt{memory\_failure\_early\_kill}, con
- \const{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
+ \constd{PR\_MCE\_KILL\_EARLY} si richiede l'emissione immediata di
\signal{SIGBUS} non appena viene rilevato un errore, mentre con
- \const{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
+ \constd{PR\_MCE\_KILL\_LATE} il segnale verrà inviato solo quando il processo
tenterà un accesso alla memoria corrotta. Questi due valori corrispondono
rispettivamente ai valori 1 e 0 di
\texttt{memory\_failure\_early\_kill}.\footnote{in sostanza nel primo caso
secondo caso prima la pagina di memoria viene tolta dallo spazio degli
indirizzi di ciascun processo, mentre il segnale viene inviato solo quei
processi che tentano di accedervi.} Si può usare per \param{arg3} anche un
- terzo valore, \const{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
+ terzo valore, \constd{PR\_MCE\_KILL\_DEFAULT}, che corrisponde a impostare
per il processo la politica di default.\footnote{si presume la politica di
default corrente, in modo da non essere influenzati da un eventuale
successivo cambiamento della stessa.} Introdotta a partire dal kernel
2.6.32.
-\item[\const{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
+\item[\constd{PR\_MCE\_KILL\_GET}] Ottiene come valore di ritorno della
funzione la politica di gestione degli errori dovuti a corruzione della
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.
-\itindbeg{child reaper}
-\item[\const{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
+\itindbeg{child~reaper}
+\item[\constd{PR\_SET\_CHILD\_SUBREAPER}] Se \param{arg2} è diverso da zero
imposta l'attributo di \textit{child reaper} per il processo, se nullo lo
cancella. Lo stato di \textit{child reaper} è una funzionalità, introdotta
con il kernel 3.4, che consente di far svolgere al processo che ha questo
con lo stato di \textit{child reaper} termina prima dei suoi discendenti,
svolgerà questo ruolo il più prossimo antenato ad avere lo stato di
\textit{child reaper},
-\item[\const{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
+\item[\constd{PR\_GET\_CHILD\_SUBREAPER}] Ottiene l'impostazione relativa allo
lo stato di \textit{child reaper} del processo chiamante, salvata come
\textit{value result} all'indirizzo puntato da \param{arg2} (da indicare
come di tipo \code{int *}). Il valore viene letto come valore logico, se
diverso da 0 lo stato di \textit{child reaper} è attivo altrimenti è
disattivo. Introdotta a partire dal kernel 3.4.
-\itindend{child reaper}
+\itindend{child~reaper}
% TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
% codice e dati, stack, brack pointer ecc. vedi
% http://git.kernel.org/linus/f606b77f1a9e362451aca8f81d8f36a3a112139e
+% TODO documentare ARCH_SET_CPUID e ARCH_GET_CPUID, introdotte con il kernel
+% 4.12, vedi https://lwn.net/Articles/721182/
+
\label{sec:prctl_operation}
\end{basedescript}
-
\subsection{La \textit{system call} \func{clone}}
\label{sec:process_clone}
indicare la unità di esecuzione generica messa a disposizione del kernel che
\texttt{sys\_clone} permette di creare.
+\itindbeg{namespace}
+\itindbeg{container}
+
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 \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
+virtualizzazione dei processi, di creare nuovi ``\textit{namespace}'' per una
+serie di proprietà generali (come l'elenco dei \ids{PID}, l'albero dei file, i
+\textit{mount point}, la rete, il sistema di IPC, ecc.). L'uso dei
+``\textit{namespace}'' consente creare gruppi di processi che vedono le
+suddette proprietà in maniera indipendente fra loro. I processi di ciascun
+gruppo vengono così eseguiti come in una sorta di spazio separato da quello
+degli altri gruppi, che costituisce poi quello che viene chiamato un
\textit{container}.
+\itindend{namespace}
+\itindend{container}
+
La \textit{system call} richiede soltanto due argomenti: il
primo, \param{flags}, consente di controllare le modalità di creazione del
nuovo \textit{task}, il secondo, \param{child\_stack}, imposta l'indirizzo
-dello \itindex{stack} \textit{stack} per il nuovo \textit{task}, e deve essere
-indicato quando si intende creare un \textit{thread}. L'esecuzione del
-programma creato da \func{sys\_clone} riprende, come per \func{fork}, da
-dopo l'esecuzione della stessa.
-
-La necessità di avere uno \itindex{stack} \textit{stack} alternativo c'è solo
-quando si intende creare un \textit{thread}, in tal caso infatti il nuovo
-\textit{task} vede esattamente la stessa memoria del \textit{task}
+dello \textit{stack} per il nuovo \textit{task}, e deve essere indicato quando
+si intende creare un \textit{thread}. L'esecuzione del programma creato da
+\func{sys\_clone} riprende, come per \func{fork}, da dopo l'esecuzione della
+stessa.
+
+La necessità di avere uno \textit{stack} alternativo c'è solo quando si
+intende creare un \textit{thread}, in tal caso infatti il nuovo \textit{task}
+vede esattamente la stessa memoria del \textit{task}
``\textsl{padre}'',\footnote{in questo caso per padre si intende semplicemente
il \textit{task} che ha eseguito \func{sys\_clone} rispetto al \textit{task}
da essa creato, senza nessuna delle implicazioni che il concetto ha per i
\textit{stack}).
Per evitare di doversi garantire contro la evidente possibilità di
-\itindex{race~condition} \textit{race condition} che questa situazione
-comporta (vedi sez.~\ref{sec:proc_race_cond} per una spiegazione della
-problematica) è necessario che il chiamante allochi preventivamente un'area di
-memoria. In genere lo si fa con una \func{malloc} che allochi un buffer che
-la funzione imposterà come \textit{stack} del nuovo processo, avendo
-ovviamente cura di non utilizzarlo direttamente nel processo chiamante.
+\textit{race condition} che questa situazione comporta (vedi
+sez.~\ref{sec:proc_race_cond} per una spiegazione della problematica) è
+necessario che il chiamante allochi preventivamente un'area di memoria. In
+genere lo si fa con una \func{malloc} che allochi un buffer che la funzione
+imposterà come \textit{stack} del nuovo processo, avendo ovviamente cura di
+non utilizzarlo direttamente nel processo chiamante.
In questo modo i due \textit{task} avranno degli \textit{stack} indipendenti e
-non si dovranno affrontare problematiche di \itindex{race~condition}
-\textit{race condition}. Si tenga presente inoltre che in molte architetture
-di processore lo \textit{stack} cresce verso il basso, pertanto in tal caso
-non si dovrà specificare per \param{child\_stack} il puntatore restituito da
-\func{malloc}, ma un puntatore alla fine del buffer da essa allocato.
+non si dovranno affrontare problematiche di \textit{race condition}. Si tenga
+presente inoltre che in molte architetture di processore lo \textit{stack}
+cresce verso il basso, pertanto in tal caso non si dovrà specificare
+per \param{child\_stack} il puntatore restituito da \func{malloc}, ma un
+puntatore alla fine del buffer da essa allocato.
Dato che tutto ciò è necessario solo per i \textit{thread} che condividono la
memoria, la \textit{system call}, a differenza della funzione di libreria che
\val{NULL}, che non imposta un nuovo \textit{stack}. Se infatti si crea un
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.
+in questo caso si applica la semantica del \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
\item[\errcode{EINVAL}] si è usata una combinazione non valida di flag o
un valore nullo per \param{child\_stack}.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare una nuova
- \struct{task\_struct} o per copiare le parti del contesto del chiamante
+ \texttt{task\_struct} o per copiare le parti del contesto del chiamante
necessarie al nuovo \textit{task}.
\item[\errcode{EPERM}] non si hanno i privilegi di amministratore
richiesti dai flag indicati.
riferimento al momento della stesura di questa sezione, cioè con il kernel
3.2.}
-\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\begin{basedescript}{\desclabelwidth{1.5 cm}\desclabelstyle{\nextlinelabel}}
-\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID}
- 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}
+\item[\constd{CLONE\_CHILD\_CLEARTID}] cancella il valore del \textit{thread
+ ID} posto 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} ed è presente dal kernel 2.5.49.
+
+\item[\constd{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.
+ utilizzato dalla librerie di gestione dei \textit{thread} ed è presente dal
+ kernel 2.5.49.
+
+\item[\constd{CLONE\_FILES}] se impostato il nuovo processo condividerà con il
+ padre la \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}]
-\item[\const{CLONE\_NEWNS}]
-\item[\const{CLONE\_NEWPID}]
-\item[\const{CLONE\_NEWUTS}]
-\item[\const{CLONE\_PARENT}]
-\item[\const{CLONE\_PARENT\_SETTID}]
-\item[\const{CLONE\_PID}]
-\item[\const{CLONE\_PTRACE}]
-\item[\const{CLONE\_SETTLS}]
-\item[\const{CLONE\_SIGHAND}]
-\item[\const{CLONE\_STOPPED}]
-\item[\const{CLONE\_SYSVSEM}]
-\item[\const{CLONE\_THREAD}]
-\item[\const{CLONE\_UNTRACED}]
-\item[\const{CLONE\_VFORK}]
-\item[\const{CLONE\_VM}]
+ \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[\constd{CLONE\_FS}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre le informazioni relative all'albero dei file, ed in
+ particolare avrà la stessa radice (vedi sez.~\ref{sec:file_chroot}), la
+ stessa directory di lavoro (vedi sez.~\ref{sec:file_work_dir}) e la stessa
+ \textit{umask} (sez.~\ref{sec:file_perm_management}). Una modifica di una
+ qualunque di queste caratteristiche in un processo, avrà effetto anche
+ sull'altro. Se assente il nuovo processo riceverà una copia delle precedenti
+ informazioni, che saranno così indipendenti per i due processi, come avviene
+ nel comportamento ordinario di un sistema unix-like.
+
+\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
+ processo condividerà con il padre il contesto dell'I/O, altrimenti, come
+ come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
+ contesto dell'I/O.
+
+ Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
+ sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
+ questi vengono trattati come se fossero lo stesso, condividendo il tempo per
+ l'accesso al disco, e possono interscambiarsi nell'accesso a disco. L'uso di
+ questo flag consente, quando più \textit{thread} eseguono dell'I/O per conto
+ dello stesso processo (ad esempio con le funzioni di I/O asincrono di
+ sez.~\ref{sec:file_asyncronous_io}), migliori prestazioni.
+
+%TODO : tutti i CLONE_NEW* attengono ai namespace, ed è meglio metterli nella
+%relativa sezione da creare a parte
+
+% \item[\constd{CLONE\_NEWIPC}] è uno dei flag ad uso dei \textit{container},
+% introdotto con il kernel 2.6.19. L'uso di questo flag crea per il nuovo
+% processo un nuovo \textit{namespace} per il sistema di IPC, sia per quello
+% di SysV (vedi sez.~\ref{sec:ipc_sysv}) che, dal kernel 2.6.30, per le code
+% di messaggi POSIX (vedi sez.~\ref{sec:ipc_posix_mq}); si applica cioè a
+% tutti quegli oggetti che non vegono identificati con un \textit{pathname}
+% sull'albero dei file.
+
+% L'uso di questo flag richiede privilegi di amministratore (più precisamente
+% la capacità \const{CAP\_SYS\_ADMIN}) e non può essere usato in combinazione
+% con \const{CLONE\_SYSVSEM}.
+
+% \item[\constd{CLONE\_NEWNET}]
+% \item[\constd{CLONE\_NEWNS}]
+% \item[\constd{CLONE\_NEWPID}]
+% \item[\constd{CLONE\_NEWUTS}]
+
+
+% TODO trattare CLONE_NEWCGROUP introdotto con il kernel 4.6, vedi
+% http://lwn.net/Articles/680566/
+
+\item[\constd{CLONE\_PARENT}]
+\item[\constd{CLONE\_PARENT\_SETTID}]
+\item[\constd{CLONE\_PID}]
+
+\item[\constd{CLONE\_PTRACE}] se questo flag viene impostato ed il processo
+ chiamante viene tracciato (vedi sez.~\ref{sec:process_ptrace}) anche il
+ figlio viene tracciato.
+
+\item[\constd{CLONE\_SETTLS}]
+\item[\constd{CLONE\_SIGHAND}]
+\item[\constd{CLONE\_STOPPED}]
+\item[\constd{CLONE\_SYSVSEM}]
+\item[\constd{CLONE\_THREAD}]
+
+\item[\constd{CLONE\_UNTRACED}] se questo flag viene impostato un processo non
+ può più forzare \const{CLONE\_PTRACE} su questo processo.
+
+\item[\constd{CLONE\_VFORK}] se questo flag viene impostato il chiamante viene
+ fermato fintato che il figlio appena creato non rilascia la sua memoria
+ virtuale con una chiamata a \func{exec} o \func{exit}, viene quindi
+ replicato il comportamento di \func{vfork}.
+
+\item[\constd{CLONE\_VM}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre la stessa memoria virtuale, e le scritture in
+ memoria fatte da uno qualunque dei processi saranno visibili dall'altro,
+ così come ogni mappatura in memoria (vedi sez.~\ref{sec:file_memory_map}).
+
+ Se non viene impostato il processo figlio otterrà una copia dello spazio
+ degli indirizzi e si otterrà il comportamento ordinario di un processo di un
+ sistema unix-like creato con la funzione \func{fork}.
\end{basedescript}
+%TODO sezione separata sui namespace
+
%TODO trattare unshare, vedi anche http://lwn.net/Articles/532748/
+%TODO: trattare la funzione setns e i namespace file descriptors (vedi
+% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
+% informazioni su setns qui: http://lwn.net/Articles/532748/
+% http://lwn.net/Articles/531498/
+
+
+% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
+% pkey_mprotect, introdotte con il kernel 4.8, vedi
+% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
%TODO trattare kcmp aggiunta con il kernel 3.5, vedi
% https://lwn.net/Articles/478111/
-\subsection{La funzione \func{ptrace}}
-\label{sec:process_ptrace}
+%\subsection{La funzione \func{ptrace}}
+%\label{sec:process_ptrace}
-Da fare
+%Da fare
% TODO: trattare PTRACE_SEIZE, aggiunta con il kernel 3.1
% TODO: trattare PTRACE_O_EXITKILL, aggiunta con il kernel 3.8 (vedi
% TODO: trattare PTRACE_O_SUSPEND_SECCOMP, aggiunta con il kernel 4.3, vedi
% http://lwn.net/Articles/656675/
-\subsection{La gestione delle operazioni in virgola mobile}
-\label{sec:process_fenv}
+%\subsection{La gestione delle operazioni in virgola mobile}
+%\label{sec:process_fenv}
-Da fare.
+%Da fare.
% TODO eccezioni ed arrotondamenti per la matematica in virgola mobile
% consultare la manpage di fenv, math_error, fpclassify, matherr, isgreater,
% isnan, nan, INFINITY
-\subsection{L'accesso alle porte di I/O}
-\label{sec:process_io_port}
+%\subsection{L'accesso alle porte di I/O}
+%\label{sec:process_io_port}
%
% TODO l'I/O sulle porte di I/O
% non c'entra nulla qui, va trovato un altro posto (altri meccanismi di I/O in
% fileintro ?)
-Da fare
+%Da fare
%\subsection{La gestione di architetture a nodi multipli}
%TODO trattare membarrier, introdotta con il kernel 4.3
% vedi http://lwn.net/Articles/369567/ http://lwn.net/Articles/369640/
% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5b25b13ab08f616efd566347d809b4ece54570d1
+% vedi anche l'ulteriore opzione "expedited" introdotta con il kernel 4.14
+% (https://lwn.net/Articles/728795/)
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
In un ambiente multitasking il concetto è essenziale, dato che un processo può
essere interrotto in qualunque momento dal kernel che mette in esecuzione un
altro processo o dalla ricezione di un segnale. Occorre pertanto essere
-accorti nei confronti delle possibili \itindex{race~condition} \textit{race
- condition} (vedi sez.~\ref{sec:proc_race_cond}) derivanti da operazioni
-interrotte in una fase in cui non erano ancora state completate.
+accorti nei confronti delle possibili \textit{race condition} (vedi
+sez.~\ref{sec:proc_race_cond}) derivanti da operazioni interrotte in una fase
+in cui non erano ancora state completate.
Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
Qualora invece si usino i \textit{thread}, in cui lo spazio degli indirizzi è
condiviso, il problema è sempre presente, perché qualunque \textit{thread} può
interromperne un altro in qualunque momento e l'atomicità di qualunque
-operazione è messa in discussione, per cui l'assenza di eventuali
-\itindex{race~condition} \textit{race condition} deve essere sempre verificata
-nei minimi dettagli.
+operazione è messa in discussione, per cui l'assenza di eventuali \textit{race
+ condition} (vedi sez.~\ref{sec:proc_race_cond}) deve essere sempre
+verificata nei minimi dettagli.
-In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
+In questo caso il sistema provvede un tipo di dato, il \typed{sig\_atomic\_t},
il cui accesso è assicurato essere atomico. In pratica comunque si può
assumere che, in ogni piattaforma su cui è implementato Linux, il tipo
\ctyp{int}, gli altri interi di dimensione inferiore ed i puntatori sono
atomici. Non è affatto detto che lo stesso valga per interi di dimensioni
maggiori (in cui l'accesso può comportare più istruzioni in assembler) o per
le strutture di dati. In tutti questi casi è anche opportuno marcare come
-\direct{volatile} le variabili che possono essere interessate ad accesso
+\dirct{volatile} le variabili che possono essere interessate ad accesso
condiviso, onde evitare problemi con le ottimizzazioni del codice.
file, o nell'accesso a meccanismi di intercomunicazione come la memoria
condivisa.
+\index{sezione~critica|(}
+
In questi casi, se non si dispone della possibilità di eseguire atomicamente
le operazioni necessarie, occorre che quelle parti di codice in cui si
-compiono le operazioni sulle risorse condivise (le cosiddette
-\index{sezione~critica} \textsl{sezioni critiche}) del programma, siano
-opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
-problematiche di questo tipo in cap.~\ref{cha:IPC}).
+compiono le operazioni sulle risorse condivise, quelle che in genere vengono
+denominate ``\textsl{sezioni critiche}'' del programma, siano opportunamente
+protette da meccanismi di sincronizzazione (vedremo alcune problematiche di
+questo tipo in cap.~\ref{cha:IPC}).
+
+\index{sezione~critica|)}
Nel caso dei \textit{thread} invece la situazione è molto più delicata e
sostanzialmente qualunque accesso in memoria (a buffer, variabili o altro) può
di sincronizzazione che anche in questo caso sono disponibili (torneremo su
queste problematiche di questo tipo in cap.~\ref{sez:thread_xxx})
-\itindbeg{deadlock} Un caso particolare di \textit{race condition} sono poi i
-cosiddetti \textit{deadlock} (traducibile in \textsl{condizione di stallo}),
-che particolarmente gravi in quanto comportano spesso il blocco completo di un
+\itindbeg{deadlock}
+
+Un caso particolare di \textit{race condition} sono poi i cosiddetti
+\textit{deadlock} (traducibile in \textsl{condizione di stallo}), che
+particolarmente gravi in quanto comportano spesso il blocco completo di un
servizio, e non il fallimento di una singola operazione. Per definizione un
\textit{deadlock} è una situazione in cui due o più processi non sono più in
grado di proseguire perché ciascuno aspetta il risultato di una operazione che
Si dice \textsl{rientrante} una funzione che può essere interrotta in
qualunque punto della sua esecuzione ed essere chiamata una seconda volta da
-un altro \itindex{thread} \textit{thread} di esecuzione senza che questo
-comporti nessun problema nell'esecuzione della stessa. La problematica è
-comune nella programmazione \itindex{thread} \textit{multi-thread}, ma si
-hanno gli stessi problemi quando si vogliono chiamare delle funzioni
-all'interno dei gestori dei segnali.
+un altro \textit{thread} di esecuzione senza che questo comporti nessun
+problema nell'esecuzione della stessa. La problematica è comune nella
+programmazione \textit{multi-thread}, ma si hanno gli stessi problemi quando
+si vogliono chiamare delle funzioni all'interno dei gestori dei segnali.
Fintanto che una funzione opera soltanto con le variabili locali è rientrante;
-queste infatti vengono allocate nello \itindex{stack} \textit{stack}, ed
-un'altra invocazione non fa altro che allocarne un'altra copia. Una funzione
-può non essere rientrante quando opera su memoria che non è nello
-\itindex{stack} \textit{stack}. Ad esempio una funzione non è mai rientrante
-se usa una \index{variabili!globali} variabile globale o
-\index{variabili!statiche} statica.
+queste infatti vengono allocate nello \textit{stack}, ed un'altra invocazione
+non fa altro che allocarne un'altra copia. Una funzione può non essere
+rientrante quando opera su memoria che non è nello \textit{stack}. Ad esempio
+una funzione non è mai rientrante se usa una variabile globale o statica.
Nel caso invece la funzione operi su un oggetto allocato dinamicamente, la
cosa viene a dipendere da come avvengono le operazioni: se l'oggetto è creato
parte del programmatore.
In genere le funzioni di libreria non sono rientranti, molte di esse ad
-esempio utilizzano \index{variabili!statiche} variabili statiche, la
-\acr{glibc} però mette a disposizione due macro di compilatore,
-\macro{\_REENTRANT} e \macro{\_THREAD\_SAFE}, la cui definizione attiva le
-versioni rientranti di varie funzioni di libreria, che sono identificate
-aggiungendo il suffisso \code{\_r} al nome della versione normale.
+esempio utilizzano variabili statiche, la \acr{glibc} però mette a
+disposizione due macro di compilatore, \macro{\_REENTRANT} e
+\macro{\_THREAD\_SAFE}, la cui definizione attiva le versioni rientranti di
+varie funzioni di libreria, che sono identificate aggiungendo il suffisso
+\code{\_r} al nome della versione normale.
\index{funzioni!rientranti|)}
% LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size
% LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC
% LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups
-% LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary PF
+% LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary
% LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap
% LocalWords: broadcast multicast multicasting memory locking mlock mlockall
% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup
projects / gapil.git / blobdiff