X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=signal.tex;h=ae4c057b0bc8e840034f83e3325a8977710ff491;hp=302b5e35f7031e15ecd249fa5593730e2000c223;hb=dcf2c2df897955ff3503a7c426025457ab456fd7;hpb=922de35645e21550b70e2e5fe5ced103a0d2e0b4 diff --git a/signal.tex b/signal.tex index 302b5e3..ae4c057 100644 --- a/signal.tex +++ b/signal.tex @@ -1,6 +1,6 @@ %% signal.tex %% -%% Copyright (C) 2000-2011 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2012 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", @@ -282,12 +282,12 @@ 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 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 -nomi, che sono standardizzati e sostanzialmente uniformi rispetto alle varie -implementazioni, che si devono usare nei programmi. Tutti i nomi e le funzioni -che concernono i segnali sono definiti nell'header di sistema \file{signal.h}. +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 nomi, che sono standardizzati e +sostanzialmente uniformi rispetto alle varie implementazioni, che si devono +usare nei programmi. Tutti i nomi e le funzioni che concernono i segnali sono +definiti nell'header di sistema \headfile{signal.h}. Il numero totale di segnali presenti è dato dalla macro \const{NSIG}, e dato che i numeri dei segnali sono allocati progressivamente, essa corrisponde @@ -352,10 +352,10 @@ cui viene salvata un'immagine della memoria del processo (il cosiddetto per esaminare lo stato dello \itindex{stack} \textit{stack} e delle variabili al momento della ricezione del segnale. -\begin{table}[htb] +\begin{table}[!htb] \footnotesize \centering - \begin{tabular}[c]{|l|c|c|p{8cm}|} + \begin{tabular}[c]{|l|c|c|l|} \hline \textbf{Segnale} &\textbf{Standard}&\textbf{Azione}&\textbf{Descrizione} \\ \hline @@ -447,7 +447,7 @@ programma al momento della terminazione. Questi segnali sono: segnale può condurre ad un ciclo infinito. % Per questo segnale le cose sono complicate dal fatto che possono esserci -% molte diverse eccezioni che \texttt{SIGFPE} non distingue, mentre lo +% molte diverse eccezioni che \signal{SIGFPE} non distingue, mentre lo % standard IEEE per le operazioni in virgola mobile definisce varie eccezioni % aritmetiche e richiede che esse siano notificate. % TODO trovare altre info su SIGFPE e trattare la notifica delle eccezioni @@ -751,8 +751,8 @@ La seconda funzione, \funcd{psignal}, deriva da BSD ed è analoga alla funzione Una modalità alternativa per utilizzare le descrizioni restituite da \func{strsignal} e \func{psignal} è quello di usare la variabile -\var{sys\_siglist}, che è definita in \file{signal.h} e può essere acceduta -con la dichiarazione: +\var{sys\_siglist}, che è definita in \headfile{signal.h} e può essere +acceduta con la dichiarazione: \includecodesnip{listati/siglist.c} L'array \var{sys\_siglist} contiene i puntatori alle stringhe di descrizione, @@ -938,7 +938,7 @@ primi Unix in cui il gestore viene disinstallato alla sua chiamata, secondo la semantica inaffidabile; anche Linux seguiva questa convenzione con le vecchie librerie del C come le \acr{libc4} e le \acr{libc5}.\footnote{nelle \acr{libc5} esiste però la possibilità di includere \file{bsd/signal.h} al - posto di \file{signal.h}, nel qual caso la funzione \func{signal} viene + posto di \headfile{signal.h}, nel qual caso la funzione \func{signal} viene ridefinita per seguire la semantica affidabile usata da BSD.} Al contrario BSD segue la semantica affidabile, non disinstallando il gestore @@ -946,7 +946,7 @@ e bloccando il segnale durante l'esecuzione dello stesso. Con l'utilizzo delle \acr{glibc} dalla versione 2 anche Linux è passato a questo comportamento. Il comportamento della versione originale della funzione, il cui uso è deprecato per i motivi visti in sez.~\ref{sec:sig_semantics}, può essere ottenuto -chiamando \func{sysv\_signal}, una volta che si sia definita la macro +chiamando \funcm{sysv\_signal}, una volta che si sia definita la macro \macro{\_XOPEN\_SOURCE}. In generale, per evitare questi problemi, l'uso di \func{signal}, che tra l'altro ha un comportamento indefinito in caso di processo \itindex{thread} multi-\textit{thread}, è da evitare; tutti i nuovi @@ -1015,7 +1015,7 @@ specificare il segnale nullo. Se la funzione viene chiamata con questo valore non viene inviato nessun segnale, ma viene eseguito il controllo degli errori, in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste. -Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in +Si tenga conto però che il sistema ricicla i \ids{PID} (come accennato in sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che esso sia realmente quello a cui si intendeva mandare il segnale. @@ -1051,7 +1051,7 @@ Una seconda funzione che può essere definita in termini di \func{kill} è \textbf{Valore} & \textbf{Significato} \\ \hline \hline - $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\ + $>0$ & Il segnale è mandato al processo con il \ids{PID} indicato.\\ 0 & Il segnale è mandato ad ogni processo del \itindex{process~group} \textit{process group} del chiamante.\\ $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\ @@ -1065,9 +1065,9 @@ Una seconda funzione che può essere definita in termini di \func{kill} è \end{table} Solo l'amministratore può inviare un segnale ad un processo qualunque, in -tutti gli altri casi l'user-ID reale o l'user-ID effettivo del processo -chiamante devono corrispondere all'user-ID reale o all'user-ID salvato della -destinazione. Fa eccezione il caso in cui il segnale inviato sia +tutti gli altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo +chiamante devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato +della destinazione. Fa eccezione il caso in cui il segnale inviato sia \signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema (si ricordi quanto visto in sez.~\ref{sec:sig_termination}), non è possibile @@ -2263,7 +2263,7 @@ lista riportata in fig.~\ref{fig:sig_safe_functions}. \func{getsockname}, \func{getsockopt}, \func{getuid}, \func{kill}, \func{link}, \func{listen}, \func{lseek}, \func{lstat}, \func{mkdir}, \func{mkfifo}, \func{open}, \func{pathconf}, \func{pause}, \func{pipe}, - \func{poll}, \func{posix\_trace\_event}, \func{pselect}, \func{raise}, + \func{poll}, \funcm{posix\_trace\_event}, \func{pselect}, \func{raise}, \func{read}, \func{readlink}, \func{recv}, \func{recvfrom}, \func{recvmsg}, \func{rename}, \func{rmdir}, \func{select}, \func{sem\_post}, \func{send}, \func{sendmsg}, \func{sendto}, @@ -2271,7 +2271,7 @@ lista riportata in fig.~\ref{fig:sig_safe_functions}. \func{setuid}, \func{shutdown}, \func{sigaction}, \func{sigaddset}, \func{sigdelset}, \func{sigemptyset}, \func{sigfillset}, \func{sigismember}, \func{signal}, \func{sigpause}, \func{sigpending}, - \func{sigprocmask}, \func{sigqueue}, \func{sigset}, \func{sigsuspend}, + \func{sigprocmask}, \func{sigqueue}, \funcm{sigset}, \func{sigsuspend}, \func{sleep}, \func{socket}, \func{socketpair}, \func{stat}, \func{symlink}, \func{sysconf}, \func{tcdrain}, \func{tcflow}, \func{tcflush}, \func{tcgetattr}, \func{tcgetgrp}, \func{tcsendbreak}, @@ -2423,7 +2423,7 @@ fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa. In particolare i campi utilizzati dai segnali \textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il -\acr{pid} e l'user-ID effettivo del processo che ha inviato il segnale, mentre +\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale, mentre per la restituzione dei dati viene usato il campo \var{si\_value}. \begin{figure}[!htb] @@ -2441,7 +2441,7 @@ Questo è una \direct{union} di tipo \struct{sigval} (la sua definizione è in fig.~\ref{fig:sig_sigval}) in cui può essere memorizzato o un valore numerico, se usata nella forma \var{sival\_int}, o un indirizzo, se usata nella forma \var{sival\_ptr}. L'unione viene usata dai segnali \textit{real-time} e da -vari meccanismi di notifica\footnote{un campo di tipo \struct{sigval\_t} è +vari meccanismi di notifica\footnote{un campo di tipo \type{sigval\_t} è presente anche nella struttura \struct{sigevent} (definita in fig.~\ref{fig:struct_sigevent}) che viene usata dai meccanismi di notifica come quelli per i timer POSIX (vedi sez.~\ref{sec:sig_timer_adv}), l'I/O @@ -2496,7 +2496,7 @@ Secondo lo standard POSIX la profondità della coda è indicata dalla costante \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32. Nel caso di Linux la coda ha una dimensione variabile; fino alla versione 2.6.7 c'era un limite massimo globale che poteva essere impostato come parametro del kernel in -\procfile{/proc/sys/kernel/rtsig-max};\footnote{ed il valore predefinito era +\sysctlfile{kernel/rtsig-max};\footnote{ed il valore predefinito era pari a 1024.} a partire dal kernel 2.6.8 il valore globale è stato rimosso e sostituito dalla risorsa \const{RLIMIT\_SIGPENDING} associata al singolo utente, che può essere modificata con \func{setrlimit} come illustrato in @@ -2708,16 +2708,16 @@ tab.~\ref{tab:sig_timer_clockid_types}. Per poter utilizzare queste funzionalità le \acr{glibc} richiedono che la macro \macro{\_POSIX\_C\_SOURCE} sia definita ad un valore maggiore o uguale di \texttt{199309L} (vedi sez.~\ref{sec:intro_gcc_glibc_std}), inoltre i -programmi che le usano devono essere collegati con la libreria delle estensioni -\textit{real-time} usando esplicitamente l'opzione \texttt{-lrt}. Si tenga -presente inoltre che la disponibilità di queste funzionalità avanzate può -essere controllato dalla definizione della macro \macro{\_POSIX\_TIMERS} ad un -valore maggiore di 0, e che le ulteriori macro +programmi che le usano devono essere collegati con la libreria delle +estensioni \textit{real-time} usando esplicitamente l'opzione +\texttt{-lrt}. Si tenga presente inoltre che la disponibilità di queste +funzionalità avanzate può essere controllato dalla definizione della macro +\macro{\_POSIX\_TIMERS} ad un valore maggiore di 0, e che le ulteriori macro \macro{\_POSIX\_MONOTONIC\_CLOCK}, \macro{\_POSIX\_CPUTIME} e \macro{\_POSIX\_THREAD\_CPUTIME} indicano la presenza dei rispettivi orologi di tipo \const{CLOCK\_MONOTONIC}, \const{CLOCK\_PROCESS\_CPUTIME\_ID} e \const{CLOCK\_PROCESS\_CPUTIME\_ID}.\footnote{tutte queste macro sono definite - in \texttt{unistd.h}, che pertanto deve essere incluso per poterle + in \headfile{unistd.h}, che pertanto deve essere incluso per poterle controllarle.} Infine se il kernel ha il supporto per gli \textit{high resolution timer} un elenco degli orologi e dei timer può essere ottenuto tramite il file \procfile{/proc/timer\_list}. @@ -2881,8 +2881,8 @@ l'orologio associato ad un \textit{thread} invece che a un processo, è } \end{functions} - % TODO, dal 2.6.39 aggiunta clock_adjtime +% TODO manca clock_nanosleep Con l'introduzione degli orologi ad alta risoluzione è divenuto possibile ottenere anche una gestione più avanzata degli allarmi; abbiamo già visto in @@ -2947,14 +2947,14 @@ meccanismo di notifica. \label{fig:struct_sigevent} \end{figure} -La struttura \struct{sigevent} (accessibile includendo \texttt{time.h}) è +La struttura \struct{sigevent} (accessibile includendo \headfile{time.h}) è riportata in fig.~\ref{fig:struct_sigevent};\footnote{la definizione effettiva dipende dall'implementazione, quella mostrata è la versione descritta nella - pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è il -più importante essendo quello che indica le modalità della notifica, gli altri -dipendono dal valore che si è specificato per \var{sigev\_notify}, si sono -riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del meccanismo di -notifica viene fatta impostando uno dei valori di + pagina di manuale di \func{timer\_create}.} il campo \var{sigev\_notify} è +il più importante essendo quello che indica le modalità della notifica, gli +altri dipendono dal valore che si è specificato per \var{sigev\_notify}, si +sono riportati in tab.~\ref{tab:sigevent_sigev_notify}. La scelta del +meccanismo di notifica viene fatta impostando uno dei valori di tab.~\ref{tab:sigevent_sigev_notify} per \var{sigev\_notify}, e fornendo gli eventuali ulteriori argomenti necessari a secondo della scelta effettuata. Diventa così possibile indicare l'uso di un segnale o l'esecuzione @@ -3262,7 +3262,7 @@ procedura: \end{enumerate*} In genere il primo passo viene effettuato allocando un'opportuna area di -memoria con \code{malloc}; in \file{signal.h} sono definite due costanti, +memoria con \code{malloc}; in \headfile{signal.h} sono definite due costanti, \const{SIGSTKSZ} e \const{MINSIGSTKSZ}, che possono essere utilizzate per allocare una quantità di spazio opportuna, in modo da evitare overflow. La prima delle due è la dimensione canonica per uno \itindex{stack} @@ -3392,6 +3392,10 @@ parte l'uso di \type{sigjmp\_buf} per \param{env}, è assolutamente identica a \func{longjmp}. +% TODO: se e quando si troverà un argomento adeguato inserire altre funzioni +% sparse attinenti ai segnali, al momento sono note solo: +% * sigreturn (funzione interna, scarsamente interessante) +% argomento a priorità IDLE (fare quando non resta niente altro da trattare) % LocalWords: kernel POSIX timer shell control ctrl kill raise signal handler