X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=3adaee33b9f00e05307f202e53e70a206cf49a1d;hp=d49b77ddff6b1cbe43bc8af6c65e0360604c7e8c;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=d655ebd2245eeffaa38553314cc30abd2b789872 diff --git a/signal.tex b/signal.tex index d49b77d..3adaee3 100644 --- a/signal.tex +++ b/signal.tex @@ -279,7 +279,7 @@ di identificarli, e le funzioni che ne stampano la descrizione. Ciascun segnale è identificato rispetto al sistema da un numero, ma l'uso diretto di questo numero da parte dei programmi è da evitare, in quanto esso -può variare a seconda dell'implementazione del sistema, e nel caso si Linux, +può variare a seconda dell'implementazione del sistema, e nel caso di Linux, anche a seconda dell'architettura hardware. Per questo motivo ad ogni segnale viene associato un nome, definendo con una macro di preprocessore una costante uguale al suddetto numero. Sono questi @@ -512,8 +512,8 @@ segnali sono: interruzione per il programma. È quello che viene generato di default dal comando \cmd{kill} o dall'invio sul terminale del carattere di controllo INTR (interrupt, generato dalla sequenza \cmd{C-c}). -\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenze che è - controllato da un'altro carattere di controllo, QUIT, corrispondente alla +\item[\const{SIGQUIT}] È analogo a \const{SIGINT} con la differenza che è + controllato da un altro carattere di controllo, QUIT, corrispondente alla sequenza \verb|C-\|. A differenza del precedente l'azione predefinita, oltre alla terminazione del processo, comporta anche la creazione di un core dump. @@ -890,9 +890,9 @@ Il numero di segnale passato in \param{signum} pu direttamente con una delle costanti definite in sez.~\ref{sec:sig_standard}. Il gestore \param{handler} invece, oltre all'indirizzo della funzione da chiamare all'occorrenza del segnale, può assumere anche i due valori costanti -\const{SIG\_IGN} con cui si dice ignorare il segnale e \const{SIG\_DFL} per +\const{SIG\_IGN} con cui si dice di ignorare il segnale e \const{SIG\_DFL} per reinstallare l'azione predefinita.\footnote{si ricordi però che i due segnali - \const{SIGKILL} e \const{SIGSTOP} non possono essere ignorati né + \const{SIGKILL} e \const{SIGSTOP} non possono essere né ignorati né intercettati; l'uso di \const{SIG\_IGN} per questi segnali non ha alcun effetto.} @@ -1076,10 +1076,9 @@ segnale; siccome alla chiamata viene cancellato ogni precedente allarme, questo può essere usato per cancellare una programmazione precedente. La funzione inoltre ritorna il numero di secondi rimanenti all'invio -dell'allarme precedentemente programmato, in modo che sia possibile -controllare se non si cancella un precedente allarme ed eventualmente -predisporre le opportune misure per gestire il caso di necessità di più -interruzioni. +dell'allarme programmato in precedenza. In questo modo è possibile controllare +se non si è cancellato un precedente allarme e predisporre eventuali misure +che permettano di gestire il caso in cui servono più interruzioni. In sez.~\ref{sec:sys_unix_time} abbiamo visto che ad ogni processo sono associati tre tempi diversi: il \textit{clock time}, l'\textit{user time} ed @@ -1113,7 +1112,7 @@ suo prototipo itimerval *value, struct itimerval *ovalue)} Predispone l'invio di un segnale di allarme alla scadenza dell'intervallo - \param{value} sul timer specificato da \func{which}. + \param{value} sul timer specificato da \param{which}. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore, nel qual caso \var{errno} assumerà uno dei valori \errval{EINVAL} o @@ -1209,7 +1208,7 @@ valore corrente di un timer senza modificarlo, \begin{prototype}{sys/time.h}{int getitimer(int which, struct itimerval *value)} - Legge in \param{value} il valore del timer specificato da \func{which}. + Legge in \param{value} il valore del timer specificato da \param{which}. \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di errore e restituisce gli stessi errori di \func{getitimer}} @@ -1241,7 +1240,7 @@ il processo non viene terminato direttamente dal gestore sia la stessa \func{abort} a farlo al ritorno dello stesso. Inoltre, sempre seguendo lo standard POSIX, prima della terminazione tutti i file aperti e gli stream saranno chiusi ed i buffer scaricati su disco. Non verranno invece eseguite le -eventuali funzioni registrate con \func{at\_exit} e \func{on\_exit}. +eventuali funzioni registrate con \func{atexit} e \func{on\_exit}. \subsection{Le funzioni di pausa e attesa} @@ -1363,7 +1362,7 @@ valore restituito in \param{rem} di 1/\const{HZ}. In realtà è possibile ottenere anche pause più precise del centesimo di -secondo usando politiche di scheduling real time come \const{SCHED\_FIFO} o +secondo usando politiche di scheduling real-time come \const{SCHED\_FIFO} o \const{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario viene evitato, e si raggiungono pause fino ai 2~ms con precisioni del $\mu$s. @@ -1398,12 +1397,6 @@ di sez.~\ref{sec:proc_termination}, invocando \cmd{forktest} con l'opzione gestore di \const{SIGCHLD}) potremo verificare che non si ha più la creazione di zombie\index{zombie}. -% è pertanto -% naturale usare un esempio che ci permette di concludere la trattazione della -% terminazione dei processi. -% In questo caso si è tratterà di illustrare un esempio relativo ad un -% gestore per che è previsto ritornare, - \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} @@ -1411,7 +1404,7 @@ di zombie\index{zombie}. \end{minipage} \normalsize \caption{Codice di una funzione generica di gestione per il segnale - \texttt{SIGCHLD}.} + \texttt{SIGCHLD}.} \label{fig:sig_sigchld_handl} \end{figure} @@ -1421,7 +1414,7 @@ comincia (\texttt{\small 6--7}) con il salvare lo stato corrente di \var{errno}, in modo da poterlo ripristinare prima del ritorno del gestore (\texttt{\small 16--17}). In questo modo si preserva il valore della variabile visto dal corso di esecuzione principale del processo, che altrimenti sarebbe -sovrascritto dal valore restituito nella successiva chiamata di \func{wait}. +sovrascritto dal valore restituito nella successiva chiamata di \func{waitpid}. Il compito principale del gestore è quello di ricevere lo stato di terminazione del processo, cosa che viene eseguita nel ciclo in @@ -1437,7 +1430,7 @@ Questo pu che molti processi figli terminino in rapida successione. Esso inoltre si presenta tutte le volte che un segnale viene bloccato: per quanti siano i segnali emessi durante il periodo di blocco, una volta che quest'ultimo sarà -rimosso sarà recapitato un solo segnale. +rimosso verrà recapitato un solo segnale. Allora, nel caso della terminazione dei processi figli, se si chiamasse \func{waitpid} una sola volta, essa leggerebbe lo stato di terminazione per un @@ -1502,8 +1495,8 @@ l'interruzione di \func{pause} venisse causata da un altro segnale. Questo codice però, a parte il non gestire il caso in cui si è avuta una precedente chiamata a \func{alarm} (che si è tralasciato per brevità), presenta una pericolosa race condition\index{\textit{race~condition}}. -Infatti se il processo viene interrotto fra la chiamata di \func{alarm} e -\func{pause} può capitare (ad esempio se il sistema è molto carico) che il +Infatti, se il processo viene interrotto fra la chiamata di \func{alarm} e +\func{pause}, può capitare (ad esempio se il sistema è molto carico) che il tempo di attesa scada prima dell'esecuzione di quest'ultima, cosicché essa sarebbe eseguita dopo l'arrivo di \const{SIGALRM}. In questo caso ci si troverebbe di fronte ad un deadlock\index{\textit{deadlock}}, in quanto @@ -1565,10 +1558,11 @@ segnale, e prendere le relative azioni conseguenti (\texttt{\small 6-11}). Questo è il tipico esempio di caso, già citato in sez.~\ref{sec:proc_race_cond}, in cui si genera una -\index{\textit{race~condition}}race condition; se infatti il segnale arriva -immediatamente dopo l'esecuzione del controllo (\texttt{\small 6}) ma prima -della cancellazione del flag (\texttt{\small 7}), la sua occorrenza sarà -perduta. +\index{\textit{race~condition}}race condition; infatti, in una situazione in +cui un segnale è già arrivato (e \var{flag} è già ad 1) se un altro segnale +segnale arriva immediatamente dopo l'esecuzione del controllo (\texttt{\small + 6}) ma prima della cancellazione del flag (\texttt{\small 7}), la sua +occorrenza sarà perduta. Questi esempi ci mostrano che per una gestione effettiva dei segnali occorrono funzioni più sofisticate di quelle illustrate finora, che hanno origine dalla @@ -1845,7 +1839,7 @@ sempre il caso di evitare l'uso di \func{signal} a favore di \func{sigaction}. \includecodesample{listati/Signal.c} \end{minipage} \normalsize - \caption{La funzione \funcd{Signal}, equivalente a \func{signal}, definita + \caption{La funzione \func{Signal}, equivalente a \func{signal}, definita attraverso \func{sigaction}.} \label{fig:sig_Signal_code} \end{figure} @@ -1879,7 +1873,7 @@ estremamente semplice, \index{\textit{signal mask}|(} Come spiegato in sez.~\ref{sec:sig_semantics} tutti i moderni sistemi unix-like -permettono si bloccare temporaneamente (o di eliminare completamente, +permettono di bloccare temporaneamente (o di eliminare completamente, impostando \const{SIG\_IGN} come azione) la consegna dei segnali ad un processo. Questo è fatto specificando la cosiddetta \textsl{maschera dei segnali} (o \textit{signal mask}) del processo\footnote{nel caso di Linux @@ -1894,7 +1888,7 @@ Uno dei problemi evidenziatisi con l'esempio di fig.~\ref{fig:sig_event_wrong} è che in molti casi è necessario proteggere delle sezioni di codice (nel caso in questione la sezione fra il controllo e la eventuale cancellazione del flag che testimoniava l'avvenuta occorrenza del segnale) in modo da essere sicuri -che essi siano eseguiti senza interruzioni. +che essi siano eseguite senza interruzioni. Le operazioni più semplici, come l'assegnazione o il controllo di una variabile (per essere sicuri si può usare il tipo \type{sig\_atomic\_t}) di @@ -2145,7 +2139,7 @@ sullo stack alternativo (nel qual caso non In genere si installa uno stack alternativo per i segnali quando si teme di avere problemi di esaurimento dello stack standard o di superamento di un -limite imposto con chiamata de tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. +limite imposto con chiamate del tipo \code{setrlimit(RLIMIT\_STACK, \&rlim)}. In tal caso infatti si avrebbe un segnale di \const{SIGSEGV}, che potrebbe essere gestito soltanto avendo abilitato uno stack alternativo. @@ -2254,10 +2248,10 @@ Queste nuove funzionalit disponibile anche con i segnali ordinari) si applicano solo ai nuovi segnali real-time; questi ultimi sono accessibili in un range di valori specificati dalle due macro \const{SIGRTMIN} e \const{SIGRTMAX},\footnote{in Linux di - solito il primo valore è 32, ed il secondo \code{\_NSIG-1}, che di norma è - 63, per un totale di 32 segnali disponibili, contro gli almeno 8 richiesti - da POSIX.1b.} che specificano il numero minimo e massimo associato ad un -segnale real-time. + solito (cioè sulla piattaforma i386) il primo valore è 33, ed il secondo + \code{\_NSIG-1}, che di norma è 64, per un totale di 32 segnali disponibili, + contro gli almeno 8 richiesti da POSIX.1b.} che specificano il numero minimo +e massimo associato ad un segnale real-time. I segnali con un numero più basso hanno una priorità maggiore e vengono consegnati per primi, inoltre i segnali real-time non possono interrompere @@ -2278,7 +2272,7 @@ gestori devono essere installati con \func{sigaction}, specificando per forma estesa \var{sa\_sigaction} (vedi sez.~\ref{sec:sig_sigaction}). In questo modo tutti i segnali real-time possono restituire al gestore una serie di informazioni aggiuntive attraverso l'argomento \struct{siginfo\_t}, la cui -definizione abbiamo già visto in fig.~\ref{fig:sig_siginfo_t}, nella +definizione è stata già vista in fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa. In particolare i campi utilizzati dai segnali real-time sono \var{si\_pid} e @@ -2308,7 +2302,7 @@ alcune definizioni essa viene identificata anche come \code{union sigval}. \end{figure} A causa delle loro caratteristiche, la funzione \func{kill} non è adatta ad -inviare segnali real-time, poichè non è in grado di fornire alcun valore +inviare segnali real-time, poiché non è in grado di fornire alcun valore per \struct{sigval\_t}; per questo motivo lo standard ha previsto una nuova funzione, \funcd{sigqueue}, il cui prototipo è: \begin{prototype}{signal.h} @@ -2333,7 +2327,7 @@ funzione, \funcd{sigqueue}, il cui prototipo Il comportamento della funzione è analogo a quello di \func{kill}, ed i privilegi occorrenti ad inviare il segnale ad un determinato processo sono gli -stessi; un valore nullo di \func{signo} permette di verificare le condizioni +stessi; un valore nullo di \param{signo} permette di verificare le condizioni di errore senza inviare nessun segnale. Se il segnale è bloccato la funzione ritorna immediatamente, se si è