\label{cha:signals}
I segnali sono il primo e più semplice meccanismo di comunicazione nei
-confronti dei processi. Non portano con se nessuna informazione che non sia il
+confronti dei processi. Non portano con sé nessuna informazione che non sia il
loro tipo; si tratta in sostanza di un'interruzione software portata ad un
processo.
In questo capitolo esamineremo i vari aspetti della gestione dei segnali,
partendo da una introduzione relativa ai concetti base con cui essi vengono
realizzati, per poi affrontarne la classificazione a secondo di uso e modalità
-di generazionem fino ad esaminare in dettaglio funzioni e le metodologie di
+di generazione fino ad esaminare in dettaglio funzioni e le metodologie di
gestione.
\var{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 di default
-quella di ingorarlo).
+quella di ignorarlo).
Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
avviene non appena questo viene rimesso in esecuzione dallo scheduler che
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 sostanzialemnte uniformi rispetto alle varie
+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}.
Esistono però dei casi in cui questo non è possibile perché renderebbe
impossibile una risposta pronta al segnale. In generale questo avviene tutte
le volte che si ha a che fare con system call che possono bloccarsi
-indenfinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
+indefinitamente, che per questo vengono chiamate \textsl{lente}. Un elenco
dei casi in cui si presenta questa situazione è il seguente:
\begin{itemize*}
\item lettura da file che possono bloccarsi in attesa di dati non ancora
presenti (come per certi file di dispositivo, la rete o le pipe).
\item scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente.
-\item apertura di un file di dipositivo che richiede operazioni non immediate
+\item apertura di un file di dispositivo che richiede operazioni non immediate
per una una risposta.
\item operazioni eseguite con \func{ioctl} che non è detto possano essere
eseguite immediatamente.
\item le funzioni di intercomunicazione che si bloccano in attesa di risposte
da altri processi.
-\item la funzione \func{pause} (usata appunto per attendere l'arrivo di un
+\item la funzione \func{pause} (usata appunto per attendere l'-arrivo di un
segnale).
\item la funzione \func{wait} (se nessun processo figlio è ancora terminato).
\end{itemize*}
\label{sec:sig_kill_raise}
Come accennato in \secref{sec:sig_types}, un segnale può essere generato
-direttamente da un processo. L'invio di un sengale generico può essere
+direttamente da un processo. L'invio di un segnale generico può essere
effettuato attraverso delle funzioni \func{kill} e \func{raise}. La prima
serve per inviare un segnale al processo corrente, ed il suo prototipo è:
\begin{prototype}{signal.h}{int raise(int sig)}
limitata da quella del timer di sistema (in genere 10~ms). Il sistema assicura
comunque che il segnale non sarà mai generato prima della scadenza programmata
(l'arrotondamento cioè è sempre effettuato per eccesso). Una seconda causa di
-potenziali ritardi è che il segnale viene generato alla scandenza del timer,
+potenziali ritardi è che il segnale viene generato alla scadenza del timer,
ma poi deve essere consegnato; se il processo è attivo (questo è sempre vero
per \macro{ITIMER\_VIRT}) la consegna è immediata, altrimenti può esserci un
ulteriore ritardo che può variare a seconda del carico del sistema.
Pone il processo in stato di sleep fino al ritorno di un manipolatore.
\bodydesc{La funzione ritorna solo dopo che un segnale è stato ricevuto ed
- il relativo manipilatore è ritornato, nel qual caso restituisce -1 e setta
+ il relativo manipolatore è ritornato, nel qual caso restituisce -1 e setta
\var{errno} a \macro{EINTR}.}
\end{prototype}
+La funzione segnala sempre una condizione di errore (il successo sarebbe
+quello di aspettare indefinitamente). In genere si usa questa funzione quando
+si vuole mettere un processo in attesa di un qualche evento specifico che non
+è sotto il suo diretto controllo (ad esempio la si può usare per far reagire
+il processo ad un segnale inviato da un altro processo).
+
+
+Se invece si vuole fare attendere un processo per un determinato intervallo di
+tempo lo standard POSIX.1 definisce la funzione \func{sleep}, il cui prototipo
+è:
+\begin{prototype}{unistd.h}{unsigned int sleep(unsigned int seconds)}
+
+ Pone il processo in stato di sleep per \param{seconds} secondi.
+
+ \bodydesc{}
+\end{prototype}
+
projects / gapil.git / blobdiff