situazione precedente.
\item[\macro{SIGXCPU}] Sta per \textit{CPU time limit exceeded}. Questo
segnale è generato quando un processo eccede il limite impostato per il
- tempo di CPU disponibile, vedi \secref{sec:sys_xxx}.
+ tempo di CPU disponibile, vedi \secref{sec:sys_resource_limit}.
\item[\macro{SIGXFSZ}] Sta per \textit{File size limit exceeded}. Questo
segnale è generato quando un processo tenta di estendere un file oltre le
dimensioni specificate dal limite impostato per le dimensioni massime di un
- file, vedi \secref{sec:sys_xxx}.
+ file, vedi \secref{sec:sys_resource_limit}.
\end{basedescript}
necessario copiarlo.
La seconda funzione deriva da BSD ed è analoga alla funzione \func{perror}
-descritta in \secref{sec:sys_strerror}; il suo prototipo è:
+descritta sempre in \secref{sec:sys_strerror}; il suo prototipo è:
\begin{prototype}{signal.h}{void psignal(int sig, const char *s)}
Stampa sullo standard error un messaggio costituito dalla stringa \param{s},
seguita da due punti ed una descrizione del segnale indicato da \param{sig}.
programmi eseguiti in background, che altrimenti sarebbero interrotti da una
successiva pressione di \texttt{C-c} o \texttt{C-y}.
-Per quanto riguarda tutte le altre system call esse vengono tradizionalmente
-classificate, proprio in base al loro comportamento nei confronti dei segnali,
-in \textsl{lente} (\textit{slow}) e \textsl{veloci} (\textit{fast}). La gran
-parte appartiene a quest'ultima categoria che non è influenzata dall'arrivo di
-un segnale. In tal caso un eventuale manipolatore viene sempre eseguito dopo
-che la system call è stata completata. Esse sono dette \textsl{veloci} proprio
-in quanto la loro esecuzione è sostanzialmente immediata e attendere per
-eseguire un manipolatore non comporta nessun inconveniente.
-
-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
-indefinitamente, (quelle che, per questo, vengono chiamate \textsl{lente}). Un
-elenco dei casi in cui si presenta questa situazione è il seguente:
+Per quanto riguarda il comportamento di tutte le altre system call si danno
+sostanzialmente due casi, a seconda che esse siano \textsl{lente}
+(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse
+appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un
+segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è
+sostanzialmente immediata; la risposta al segnale viene sempre data dopo che
+la system call è stata completata, in quanto attendere per eseguire un
+manipolatore non comporta nessun inconveniente.
+
+In alcuni casi però alcune system call (che per questo motivo vengono chiamate
+\textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può
+attendere la conclusione della sistem call, perché questo renderebbe
+impossibile una risposta pronta al segnale, per cui il manipolatore viene
+eseguito prima che la system call sia ritornata. 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
+\item la lettura da file che possono bloccarsi in attesa di dati non ancora
+ presenti (come per certi file di dispositivo, i socket o le pipe).
+\item la scrittura sugli stessi file, nel caso in cui dati non possano essere
accettati immediatamente.
-\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
+\item l'apertura di un file di dispositivo che richiede operazioni non
+ immediate per una una risposta.
+\item le 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.
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 \macro{SIGALRM}. La funzione prende come parametri
-delle strutture di tipo \var{timespec}, la cui definizione è riportata in
-\figref{fig:sig_timespec_def}, che permettono di specificare un tempo con una
-precisione (teorica) fino al nanosecondo.
+delle strutture di tipo \var{timespec}, la cui definizione è riportata in
+\figref{fig:sys_timeval_struct}, che permettono di specificare un tempo con
+una precisione (teorica) fino al nanosecondo.
La funzione risolve anche il problema di proseguire l'attesa dopo
l'interruzione dovuta ad un segnale; infatti in tal caso in \param{rem} viene
questo motivo il valore restituito in \param{rem} è sempre arrotondato al
multiplo successivo di 1/\macro{HZ}.
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \begin{lstlisting}[labelstep=0]{}%,frame=,indent=1cm]{}
-struct timespec {
- time_t tv_sec; /* seconds */
- long tv_nsec; /* nanoseconds */
-};
- \end{lstlisting}
- \end{minipage}
- \normalsize
- \caption{La struttura \var{timespec} di \func{nanosleep}.}
- \label{fig:sig_timespec_def}
-\end{figure}
-
In realtà è possibile ottenere anche pause più precise del centesimo di
secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o
\macro{SCHED\_RR}; in tal caso infatti il meccanismo di scheduling ordinario
#include <sys/wait.h>
#include "macro.h"
-void Hand_CHLD(int sig)
+void sigchld_hand(int sig)
{
int errno_save;
int status;
projects / gapil.git / blobdiff