\textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
per tutto il tempo che passa fra la generazione del segnale e la sua consegna
esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo \itindex{scheduler} scheduler quando,
-riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \struct{task\_struct} e mette in esecuzione il gestore.
+procedura viene effettuata dallo \textit{scheduler} quando, riprendendo
+l'esecuzione del processo in questione, verifica la presenza del segnale nella
+\struct{task\_struct} e mette in esecuzione il gestore.
In questa semantica un processo ha la possibilità di bloccare la consegna dei
segnali, in questo caso, se l'azione per il suddetto segnale non è quella di
ignorarlo.
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo
-\itindex{scheduler} scheduler che esegue l'azione specificata. Questo a meno
-che il segnale in questione non sia stato bloccato prima della notifica, nel
-qual caso l'invio non avviene ed il segnale resta \textsl{pendente}
-indefinitamente.
+avviene non appena questo viene rimesso in esecuzione dallo \textit{scheduler}
+che esegue l'azione specificata. Questo a meno che il segnale in questione non
+sia stato bloccato prima della notifica, nel qual caso l'invio non avviene ed
+il segnale resta \textsl{pendente} indefinitamente.
Quando lo si sblocca un segnale \textsl{pendente} sarà subito notificato. Si
tenga presente però che tradizionalmente i segnali \textsl{pendenti} non si
Questo file costituisce il cosiddetto \textit{core dump}, e contenendo
l'immagine della memoria del processo, consente di risalire allo stato dello
-\itindex{stack} \textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima
-della terminazione. Questo permette di esaminare il contenuto del file un
-secondo tempo con un apposito programma (un \textit{debugger} come \cmd{gdb})
-per investigare sulla causa dell'errore, ed in particolare, grazie appunto ai
-dati dello \itindex{stack} \textit{stack}, consente di identificare quale
-funzione ha causato l'errore.
+\textit{stack} (vedi sez.~\ref{sec:proc_mem_layout}) prima della
+terminazione. Questo permette di esaminare il contenuto del file un secondo
+tempo con un apposito programma (un \textit{debugger} come \cmd{gdb}) per
+investigare sulla causa dell'errore, ed in particolare, grazie appunto ai dati
+dello \textit{stack}, consente di identificare quale funzione ha causato
+l'errore.
Si tenga presente che il \textit{core dump} viene creato non solo in caso di
errore effettivo, ma anche se il segnale per cui la sua creazione è prevista
\hline
T & L'azione predefinita è terminare il processo.\\
C & L'azione predefinita è terminare il processo e scrivere un
- \itindex{core~dump} \textit{core dump}.\\
+ \textit{core dump}.\\
I & L'azione predefinita è ignorare il segnale.\\
S & L'azione predefinita è fermare il processo.\\
\hline
L'azione predefinita per tutti questi segnali è causare la terminazione del
processo che li ha causati. In genere oltre a questo il segnale provoca pure
-la registrazione su disco di un file di \itindex{core~dump} \textit{core
- dump}, che un debugger può usare per ricostruire lo stato del programma al
-momento della terminazione. Questi segnali sono:
+la registrazione su disco di un file di \textit{core dump}, che un debugger
+può usare per ricostruire lo stato del programma al momento della
+terminazione. Questi segnali sono:
\begin{basedescript}{\desclabelwidth{2.0cm}}
\item[\signal{SIGFPE}] Riporta un errore aritmetico fatale. Benché il nome
derivi da \textit{floating point exception} si applica a tutti gli errori
controllato da un altro carattere di controllo, ``\textit{QUIT}'',
corrispondente alla sequenza \texttt{C-\bslash} sulla tastiera. A differenza
del precedente l'azione predefinita, oltre alla terminazione del processo,
- comporta anche la creazione di un \itindex{core~dump} \textit{core dump}.
- In genere lo si può pensare come corrispondente ad una condizione di errore
- del programma rilevata dall'utente. Per questo motivo non è opportuno fare
- eseguire al gestore di questo segnale le operazioni di pulizia normalmente
- previste (tipo la cancellazione di file temporanei), dato che in certi casi
- esse possono eliminare informazioni utili nell'esame dei \itindex{core~dump}
- \textit{core dump}.
+ comporta anche la creazione di un \textit{core dump}. In genere lo si può
+ pensare come corrispondente ad una condizione di errore del programma
+ rilevata dall'utente. Per questo motivo non è opportuno fare eseguire al
+ gestore di questo segnale le operazioni di pulizia normalmente previste
+ (tipo la cancellazione di file temporanei), dato che in certi casi esse
+ possono eliminare informazioni utili nell'esame dei \textit{core dump}.
\item[\signal{SIGKILL}] Il nome è utilizzato per terminare in maniera immediata
qualunque programma. Questo segnale non può essere né intercettato, né
tempo di CPU disponibile, vedi sez.~\ref{sec:sys_resource_limit}. Fino al
kernel 2.2 terminava semplicemente il processo, a partire dal kernel 2.4,
seguendo le indicazioni dello standard POSIX.1-2001 viene anche generato un
- \itindex{core~dump} \textit{core dump}.
+ \textit{core dump}.
\item[\signal{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
segnale è generato quando un processo tenta di estendere un file oltre le
dimensioni specificate dal limite impostato per le dimensioni massime di un
file, vedi sez.~\ref{sec:sys_resource_limit}. Fino al kernel 2.2 terminava
semplicemente il processo, a partire dal kernel 2.4, seguendo le indicazioni
- dello standard POSIX.1-2001 viene anche generato un \itindex{core~dump}
- \textit{core dump}.
+ dello standard POSIX.1-2001 viene anche generato un \textit{core dump}.
\item[\signal{SIGLOST}] Sta per \textit{Resource lost}. Tradizionalmente è il
segnale che viene generato quando si perde un advisory lock su un file su
arrotondato al multiplo successivo di 1/\const{HZ}.
Con i kernel della serie 2.4 in realtà era possibile ottenere anche pause più
-precise del centesimo di secondo usando politiche di \itindex{scheduler}
-scheduling \textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in
-tal caso infatti il calcolo sul numero di interruzioni del timer veniva
-evitato utilizzando direttamente un ciclo di attesa con cui si raggiungevano
-pause fino ai 2~ms con precisioni del $\mu$s. Questa estensione è stata
-rimossa con i kernel della serie 2.6, che consentono una risoluzione più alta
-del timer di sistema; inoltre a partire dal kernel 2.6.21, \func{nanosleep}
-può avvalersi del supporto dei timer ad alta risoluzione, ottenendo la massima
-precisione disponibile sull'hardware della propria macchina.
+precise del centesimo di secondo usando politiche di \textit{scheduling}
+\textit{real-time} come \const{SCHED\_FIFO} o \const{SCHED\_RR} (vedi
+sez.~\ref{sec:proc_real_time}); in tal caso infatti il calcolo sul numero di
+interruzioni del timer veniva evitato utilizzando direttamente un ciclo di
+attesa con cui si raggiungevano pause fino ai 2~ms con precisioni del
+$\mu$s. Questa estensione è stata rimossa con i kernel della serie 2.6, che
+consentono una risoluzione più alta del timer di sistema; inoltre a partire
+dal kernel 2.6.21, \func{nanosleep} può avvalersi del supporto dei timer ad
+alta risoluzione, ottenendo la massima precisione disponibile sull'hardware
+della propria macchina.
\subsection{Un esempio elementare}
projects / gapil.git / blobdiff