tutti i problemi precedenti. In questa semantica i segnali vengono
\textsl{generati} dal kernel per un processo all'occorrenza dell'evento che
causa il segnale. In genere questo viene fatto dal kernel impostando l'apposito
-campo della \var{task\_struct} del processo nella process table (si veda
+campo della \struct{task\_struct} del processo nella process table (si veda
\figref{fig:proc_task_struct}).
Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
procedura viene effettuata dallo scheduler\index{scheduler} quando,
riprendendo l'esecuzione del processo in questione, verifica la presenza del
-segnale nella \var{task\_struct} e mette in esecuzione il gestore.
+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
Come accennato quando un segnale viene generato, se la sua azione predefinita
non è quella di essere ignorato, il kernel prende nota del fatto nella
-\var{task\_struct} del processo; si dice così che il segnale diventa
+\struct{task\_struct} del processo; si dice così che il segnale diventa
\textsl{pendente} (o \textit{pending}), e rimane tale fino al momento in cui
verrà notificato al processo (o verrà specificata come azione quella di
ignorarlo).
funzione \func{strerror} (si veda \secref{sec:sys_strerror}) per gli errori:
\begin{prototype}{string.h}{char *strsignal(int signum)}
Ritorna il puntatore ad una stringa che contiene la descrizione del segnale
- \var{signum}.
+ \param{signum}.
\end{prototype}
\noindent dato che la stringa è allocata staticamente non se ne deve
modificare il contenuto, che resta valido solo fino alla successiva chiamata
\label{tab:sig_setitimer_values}
\end{table}
-Il valore della struttura specificata \param{value} viene usato per impostare il
-timer, se il puntatore \param{ovalue} non è nullo il precedente valore viene
-salvato qui. I valori dei timer devono essere indicati attraverso una
-struttura \type{itimerval}, definita in \figref{fig:file_stat_struct}.
+Il valore della struttura specificata \param{value} viene usato per impostare
+il timer, se il puntatore \param{ovalue} non è nullo il precedente valore
+viene salvato qui. I valori dei timer devono essere indicati attraverso una
+struttura \struct{itimerval}, definita in \figref{fig:file_stat_struct}.
La struttura è composta da due membri, il primo, \var{it\_interval} definisce
il periodo del timer; il secondo, \var{it\_value} il tempo mancante alla
-scadenza. Entrambi esprimono i tempi tramite una struttura \var{timeval} che
+scadenza. Entrambi esprimono i tempi tramite una struttura \struct{timeval} che
permette una precisione fino al microsecondo.
Ciascun timer decrementa il valore di \var{it\_value} fino a zero, poi invia
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{itimerval}, che definisce i valori dei timer di
- sistema.}
+ \caption{La struttura \structd{itimerval}, che definisce i valori dei timer
+ di sistema.}
\label{fig:sig_itimerval}
\end{figure}
indipendente da \func{alarm}\footnote{nel caso di Linux questo è fatto
utilizzando direttamente il timer del kernel.} e sia utilizzabile senza
interferenze con l'uso di \const{SIGALRM}. La funzione prende come parametri
-delle strutture di tipo \var{timespec}, la cui definizione è riportata in
+delle strutture di tipo \struct{timespec}, la cui definizione è riportata in
\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
una precisione (teorica) fino al nanosecondo.
nullo e \param{oldact} non nullo) di superare uno dei limiti di \func{signal},
che non consente di ottenere l'azione corrente senza installarne una nuova.
-Entrambi i puntatori fanno riferimento alla struttura \var{sigaction}, tramite
-la quale si specificano tutte le caratteristiche dell'azione associata ad un
-segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è definita
-secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
+Entrambi i puntatori fanno riferimento alla struttura \struct{sigaction},
+tramite la quale si specificano tutte le caratteristiche dell'azione associata
+ad un segnale. Anch'essa è descritta dallo standard POSIX.1 ed in Linux è
+definita secondo quanto riportato in \figref{fig:sig_sigaction}. Il campo
\var{sa\_restorer}, non previsto dallo standard, è obsoleto e non deve essere
più usato.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{sigaction}.}
+ \caption{La struttura \structd{sigaction}.}
\label{fig:sig_sigaction}
\end{figure}
\secref{sec:sig_specific_features}).\\
\hline
\end{tabular}
- \caption{Valori del campo \var{sa\_flag} della struttura \var{sigaction}.}
+ \caption{Valori del campo \var{sa\_flag} della struttura \struct{sigaction}.}
\label{tab:sig_sa_flag}
\end{table}
stata aggiunta nei kernel della serie 2.1.x con l'introduzione dei segnali
real-time (vedi \secref{sec:sig_real_time}). In precedenza era possibile
ottenere alcune informazioni addizionali usando \var{sa\_handler} con un
- secondo parametro addizionale di tipo \var{struct sigcontext}, che adesso è
+ secondo parametro addizionale di tipo \var{sigcontext}, che adesso è
deprecato.} di utilizzare due forme diverse di gestore, da
specificare, a seconda dell'uso o meno del flag \const{SA\_SIGINFO},
rispettivamente attraverso i campi \var{sa\_sigaction} o \var{sa\_handler},
questi vengono addirittura definiti come \ctyp{union}): la prima è quella
classica usata anche con \func{signal}, la seconda permette invece di usare un
gestore in grado di ricevere informazioni più dettagliate dal sistema,
-attraverso la struttura \type{siginfo\_t}, riportata in
+attraverso la struttura \struct{siginfo\_t}, riportata in
\figref{fig:sig_siginfo_t}.
\begin{figure}[!htb]
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{siginfo\_t}.}
+ \caption{La struttura \structd{siginfo\_t}.}
\label{fig:sig_siginfo_t}
\end{figure}
Benché sia possibile usare nello stesso programma sia \func{sigaction} che
\func{signal} occorre molta attenzione, in quanto le due funzioni possono
interagire in maniera anomala. Infatti l'azione specificata con
-\var{sigaction} contiene un maggior numero di informazioni rispetto al
-semplice indirizzo del gestore restituito da \func{signal}. Per questo
-motivo se si usa quest'ultima per installare un gestore sostituendone uno
+\struct{sigaction} contiene un maggior numero di informazioni rispetto al
+semplice indirizzo del gestore restituito da \func{signal}. Per questo motivo
+se si usa quest'ultima per installare un gestore sostituendone uno
precedentemente installato con \func{sigaction}, non sarà possibile effettuare
un ripristino corretto dello stesso.
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
- essa è mantenuta dal campo \var{blocked} della \var{task\_struct} del
+ essa è mantenuta dal campo \var{blocked} della \struct{task\_struct} del
processo.} cioè l'insieme dei segnali la cui consegna è bloccata. Abbiamo
accennato in \secref{sec:proc_fork} che la \textit{signal mask} viene
ereditata dal padre alla creazione di un processo figlio, e abbiamo visto al
paragrafo precedente che essa può essere modificata, durante l'esecuzione di
-un gestore, attraverso l'uso dal campo \var{sa\_mask} di \var{sigaction}.
+un gestore, attraverso l'uso dal campo \var{sa\_mask} di \struct{sigaction}.
Uno dei problemi evidenziatisi con l'esempio di \secref{fig:sig_event_wrong} è
che in molti casi è necessario proteggere delle sezioni di codice (nel caso in
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{stack\_t}.}
+ \caption{La struttura \structd{stack\_t}.}
\label{fig:sig_stack_t}
\end{figure}
-Il campo \var{ss\_sp} di \var{stack\_t} indica l'indirizzo base dello stack,
+Il campo \var{ss\_sp} di \struct{stack\_t} indica l'indirizzo base dello stack,
mentre \var{ss\_size} ne indica la dimensione; il campo \var{ss\_flags} invece
indica lo stato dello stack. Nell'indicare un nuovo stack occorre
inizializzare \var{ss\_sp} e \var{ss\_size} rispettivamente al puntatore e
con un numero minore, che pertanto hanno una priorità maggiore.
\item è stata introdotta la possibilità di restituire dei dati al
gestore, attraverso l'uso di un campo apposito nella struttura
- \type{siginfo\_t} accessibile tramite gestori di tipo
+ \struct{siginfo\_t} accessibile tramite gestori di tipo
\var{sa\_sigaction}.
\end{itemize*}
Si tenga presente che questi nuovi segnali non sono associati a nessun evento
sepcifico (a meno di non utilizzarli, come vedremo in
\secref{sec:file_asyncronous_io}, per l'I/O asincrono) e devono essere inviati
-esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre
-ai campi \var{si\_pid} e \var{si\_uid} di \type{siginfo\_t} una struttura
-\type{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
+esplicitamente. Tutti i segnali real-time restituiscono al gestore, oltre ai
+campi \var{si\_pid} e \var{si\_uid} di \struct{siginfo\_t} una struttura
+\struct{sigval} (riportata in \figref{fig:sig_sigval}) in cui può essere
restituito al processo un valore o un indirizzo, che costituisce il meccanismo
con cui il segnale è in grado di inviare una ulteriore informazione al
processo.
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \type{sigval}, usata dai segnali real time per
+ \caption{La struttura \structd{sigval}, usata dai segnali real time per
restituire dati al gestore.}
\label{fig:sig_sigval}
\end{figure}
A causa di queste loro caratteristiche, la funzione \func{kill} non è adatta
ad inviare un segnale real time, in quanto non è in grado di fornire alcun
-valore per \var{sigval}; per questo motivo lo standard ha previsto una nuova
-funzione, \func{sigqueue}, il cui prototipo è:
+valore per \struct{sigval}; per questo motivo lo standard ha previsto una
+nuova funzione, \func{sigqueue}, il cui prototipo è:
\begin{prototype}{signal.h}
{int sigqueue(pid\_t pid, int signo, const union sigval value)}
di errore senza inviare nessun segnale.
Se il segnale è bloccato la funzione ritorna immediatamente, se si è
-installato un gestore con \const{SA\_SIGINFO} e ci sono risorse
-disponibili, vale a dire che c'è posto nella coda\footnote{la profondità della
- coda è indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante
- costanti di sistema definite dallo standard POSIX, che non abbiamo riportato
+installato un gestore con \const{SA\_SIGINFO} e ci sono risorse disponibili,
+vale a dire che c'è posto nella coda\footnote{la profondità della coda è
+ indicata dalla costante \const{SIGQUEUE\_MAX}, una della tante costanti di
+ sistema definite dallo standard POSIX, che non abbiamo riportato
esplicitamente in \secref{sec:sys_limits}. Il suo valore minimo secondo lo
standard, \const{\_POSIX\_SIGQUEUE\_MAX}, è pari a 32.}, esso viene inserito
e diventa pendente; una volta consegnato riporterà nel campo \var{si\_code} di
-\var{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value} riceverà
-quanto inviato con \param{value}. Se invece si è installato un gestore
-nella forma classica il segnale sarà generato, ma tutte le caratteristiche
-tipiche dei segnali real-time (priorità e coda) saranno perse.
+\struct{siginfo} il valore \const{SI\_QUEUE} e il campo \var{si\_value}
+riceverà quanto inviato con \param{value}. Se invece si è installato un
+gestore nella forma classica il segnale sarà generato, ma tutte le
+caratteristiche tipiche dei segnali real-time (priorità e coda) saranno perse.
Lo standard POSIX.1b definisce inoltre delle nuove funzioni che permettono di
gestire l'attesa di segnali specifici su una coda, esse servono in particolar
projects / gapil.git / blobdiff