valore della costante \texttt{HZ}, di cui abbiamo già parlato in
sez.~\ref{sec:proc_hierarchy}.} in quanto le temporizzazioni erano calcolate
in numero di interruzioni del timer (i cosiddetti \itindex{jiffies}
-''\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
+``\textit{jiffies}''), ed era assicurato soltanto che il segnale non sarebbe
stato mai generato prima della scadenza programmata (l'arrotondamento cioè era
effettuato per eccesso).\footnote{questo in realtà non è del tutto vero a
causa di un bug, presente fino al kernel 2.6.12, che in certe circostanze
messaggi POSIX (vedi
sez.~\ref{sec:ipc_posix_mq}).\footnotemark\\
\const{SI\_ASYNCIO}& una operazione di I/O asincrono (vedi
- sez.~\ref{sec:file_asyncronous_access}) è stata
+ sez.~\ref{sec:file_asyncronous_io}) è stata
completata.\\
\const{SI\_SIGIO} & segnale di \signal{SIGIO} da una coda (vedi
sez.~\ref{sec:file_asyncronous_operation}).\\
dal timer di sistema che governa lo \textit{scheduler},\footnote{e quindi
limitate dalla frequenza dello stesso che si ricordi, come già illustrato in
sez.~\ref{sec:proc_hierarchy}, è data dal valore della costante
- \texttt{HZ}.} i contatori usati per il calcolo dei tempo infatti erano
+ \texttt{HZ}.} i contatori usati per il calcolo dei tempi infatti erano
basati sul numero di \itindex{jiffies} \textit{jiffies} che vengono
incrementati ad ogni \textit{clock tick} del timer di sistema.\footnote{il che
comportava anche, come accennato in sez.~\ref{sec:sig_alarm_abort} per
Per usare queste funzionalità ed ottenere risoluzioni temporali più accurate,
occorre però un opportuno supporto da parte del kernel, ed i cosiddetti
-\textit{high resolution timer} che consentono di fare ciò sono stati
-introdotti nel kernel ufficiale solo a partire dalla versione
-2.6.21.\footnote{deve essere stata abilitata l'opzione di compilazione
- \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili anche in
- precedenza come patch facenti parte dello sviluppo delle estensioni
+\itindex{high~resolution~timer} \textit{high resolution timer} che consentono
+di fare ciò sono stati introdotti nel kernel ufficiale solo a partire dalla
+versione 2.6.21.\footnote{deve essere stata abilitata l'opzione di
+ compilazione \texttt{CONFIG\_HIGH\_RES\_TIMERS}, erano però disponibili
+ anche in precedenza come patch facenti parte dello sviluppo delle estensioni
\textit{real-time} del kernel, per cui alcune distribuzioni possono avere
questo supporto anche con versioni precedenti del kernel.} Le funzioni
definite dallo standard POSIX per gestire orologi ad alta definizione però
(la cui definizione è riportata fig.~\ref{fig:sys_timespec_struct}). Il campo
\var{it\_value} indica la prima scadenza dell'allarme. Di default, quando il
valore di \param{flags} è nullo, questo valore viene considerato come un
-intervallo relativo al tempo corrente,\footnote{il primo allarme scatterà cioè
- dopo il numero di secondi e nanosecondi indicati da questo campo.} se invece
-si usa per \param{flags} il valore \const{TIMER\_ABSTIME},\footnote{al momento
- questo è l'unico valore valido per \param{flags}.} \var{it\_value} viene
-considerato come un valore assoluto rispetto al valore usato dall'orologio a
-cui è associato il timer.\footnote{quindi a seconda dei casi lo si potrà
- indicare o come un tempo assoluto, quando si opera rispetto all'orologio di
- sistema (nel qual caso il valore deve essere in secondi e nanosecondi dalla
- \textit{epoch}) o come numero di secondi o nanosecondi rispetto alla
- partenza di un orologio di CPU, quando si opera su uno di questi.} Infine
-un valore nullo di \var{it\_value}\footnote{per nullo si intende con valori
- nulli per entrambi i i campi \var{tv\_sec} e \var{tv\_nsec}.} può essere
-utilizzato, indipendentemente dal tipo di orologio utilizzato, per disarmare
-l'allarme.
+intervallo relativo al tempo corrente, il primo allarme scatterà cioè dopo il
+numero di secondi e nanosecondi indicati da questo campo. Se invece si usa
+per \param{flags} il valore \const{TIMER\_ABSTIME}, che al momento è l'unico
+valore valido per \param{flags}, allora \var{it\_value} viene considerato come
+un valore assoluto rispetto al valore usato dall'orologio a cui è associato il
+timer.\footnote{quindi a seconda dei casi lo si potrà indicare o come un tempo
+ assoluto, quando si opera rispetto all'orologio di sistema (nel qual caso il
+ valore deve essere in secondi e nanosecondi dalla \textit{epoch}) o come
+ numero di secondi o nanosecondi rispetto alla partenza di un orologio di
+ CPU, quando si opera su uno di questi.} Infine un valore nullo di
+\var{it\_value}, dover per nullo si intende con valori nulli per entrambi i
+campi \var{tv\_sec} e \var{tv\_nsec}, può essere utilizzato, indipendentemente
+dal tipo di orologio utilizzato, per disarmare l'allarme.
Il campo \var{it\_interval} di \struct{itimerspec} viene invece utilizzato per
-impostare un allarme periodico. Se il suo valore è nullo (se cioè sono nulli
-tutti e due i valori di detta struttura \struct{timespec}) l'allarme scatterà
-una sola volta secondo quando indicato con \var{it\_value}, altrimenti il
-valore specificato verrà preso come l'estensione del periodo di ripetizione
-della generazione dell'allarme, che proseguirà indefinitamente fintanto che
-non si disarmi il timer.
+impostare un allarme periodico. Se il suo valore è nullo, se cioè sono nulli
+tutti e due i due campi \var{tv\_sec} e \var{tv\_nsec} di detta struttura
+\struct{timespec}, l'allarme scatterà una sola volta secondo quando indicato
+con \var{it\_value}, altrimenti il valore specificato nella struttura verrà
+preso come l'estensione del periodo di ripetizione della generazione
+dell'allarme, che proseguirà indefinitamente fintanto che non si disarmi il
+timer.
Se il timer era già stato armato la funzione sovrascrive la precedente
impostazione, se invece si indica come prima scadenza un tempo già passato,
projects / gapil.git / blobdiff