X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=3adaee33b9f00e05307f202e53e70a206cf49a1d;hp=4643eafdef097cdd9153137da192768c3a317ada;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=5845ec6abcd61687211f186073c8a56276959bdb diff --git a/signal.tex b/signal.tex index 4643eaf..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. @@ -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 è