Correzioni ortografiche e aggiornamento di alcune voci per l'indice
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 26 Oct 2002 13:23:47 +0000 (13:23 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 26 Oct 2002 13:23:47 +0000 (13:23 +0000)
fileadv.tex
intro.tex
ipc.tex
prochand.tex
signal.tex

index 1932eca..3d1c9f8 100644 (file)
@@ -33,7 +33,8 @@ affrontare nelle operazioni di I/O, che 
 devono eseguire operazioni che possono bloccarsi su più file descriptor:
 mentre si è bloccati su uno di essi su di un'altro potrebbero essere presenti
 dei dati; così che nel migliore dei casi si avrebbe una lettura ritardata
-inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un deadlock.
+inutilmente, e nel peggiore si potrebbe addirittura arrivare ad un
+\textit{deadlock}.
 
 Abbiamo già accennato in \secref{sec:file_open} che è possibile prevenire
 questo tipo di comportamento aprendo un file in modalità
@@ -976,7 +977,8 @@ come maschera binaria ottenuta dall'OR di uno o pi
                              riportati sul file. Ne viene fatta una copia
                              privata cui solo il processo chiamante ha
                              accesso.  Le modifiche sono mantenute attraverso
-                             il meccanismo del \textit{copy on write} e
+                             il meccanismo del 
+                             \textit{copy on write}\index{copy on write} e
                              salvate su swap in caso di necessità. Non è
                              specificato se i cambiamenti sul file originale
                              vengano riportati sulla regione
@@ -988,7 +990,8 @@ come maschera binaria ottenuta dall'OR di uno o pi
     \macro{MAP\_EXECUTABLE}& Ignorato. \\
     \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva
                              delle pagine di swap ad uso del meccanismo di
-                             \textit{copy on write} per mantenere le
+                             \textit{copy on write}\index{copy on write}
+                             per mantenere le
                              modifiche fatte alla regione mappata, in
                              questo caso dopo una scrittura, se non c'è più
                              memoria disponibile, si ha l'emissione di
@@ -1234,8 +1237,8 @@ sovrapposizioni, e garantire la atomicit
 
 La prima modalità di file locking che è stata implementata nei sistemi
 unix-like è quella che viene usualmente chiamata \textit{advisory
-  locking},\footnote{Stevens in APUE fa riferimento a questo argomento come al
-  \textit{record locking}, dizione utilizzata anche dal manuale delle
+  locking},\footnote{Stevens in \cite{APUE} fa riferimento a questo argomento
+  come al \textit{record locking}, dizione utilizzata anche dal manuale delle
   \acr{glibc}; nelle pagine di manuale si parla di \textit{discretionary file
     lock} per \func{fcntl} e di \textit{advisory locking} per \func{flock},
   mentre questo nome viene usato anche da Stevens per riferirsi al
@@ -1272,7 +1275,7 @@ sono implementati in maniera completamente indipendente nelle due interfacce,
 che pertanto possono coesistere senza interferenze.
 
 Entrambe le interfacce prevedono la stessa procedura di funzionamento: si
-inizia sempre con il richiere l'opportuno \textit{file lock} (un
+inizia sempre con il richiedere l'opportuno \textit{file lock} (un
 \textit{exclusive lock} per una scrittura, uno \textit{shared lock} per una
 lettura) prima di eseguire l'accesso ad un file.  Se il lock viene acquisito
 il processo prosegue l'esecuzione, altrimenti (a meno di non aver richiesto un
@@ -1329,14 +1332,14 @@ costanti riportate in \tabref{tab:file_flock_operation}.
 I primi due valori, \macro{LOCK\_SH} e \macro{LOCK\_EX} permettono di
 richiedere un \textit{file lock}, ed ovviamente devono essere usati in maniera
 alternativa. Se si specifica anche \macro{LOCK\_NB} la funzione non si
-bloccherà qualora il lock non possa essere aqcuisito, ma ritornerà subito con
+bloccherà qualora il lock non possa essere acquisito, ma ritornerà subito con
 un errore di \macro{EWOULDBLOCK}. Per rilasciare un lock si dovrà invece usare
 \macro{LOCK\_NB}.
 
 La semantica del file locking di BSD è diversa da quella del file locking
 POSIX, in particolare per quanto riguarda il comportamento dei lock nei
 confronti delle due funzioni \func{dup} e \func{fork}.  Per capire queste
-differenze occore prima descrivere con maggiore dettaglio come viene
+differenze occorre prima descrivere con maggiore dettaglio come viene
 realizzato il file locking nel kernel.
 
 In \figref{fig:file_flock_struct} si è riportato uno schema essenziale
@@ -1473,7 +1476,7 @@ struct flock {
 
 L'operazione effettivamente svolta dalla funzione è stabilita dal valore
 dall'argomento \param{cmd} che, come già riportato in \secref{sec:file_fcntl},
-specifica l'azione da compiere; i valori relativi al file loking sono tre:
+specifica l'azione da compiere; i valori relativi al file locking sono tre:
 \begin{basedescript}{\desclabelwidth{2.0cm}}
 \item[\macro{F\_GETLK}] verifica se il file lock specificato dalla struttura
   puntata da \param{lock} non è bloccato da qualche altro lock: in caso
@@ -1574,7 +1577,7 @@ allo stesso file (che sia stato ottenuto con una \func{dup} o con una
 che quello che conta è solo il \acr{pid} del processo. Da questo deriva una
 ulteriore sottile differenza di comportamento: dato che alla chiusura di un
 file i lock ad esso associati vengono rimossi, nella semantica POSIX basterà
-chiudere un file descriptor per cancellare tutti i lock realtivi al file cui
+chiudere un file descriptor per cancellare tutti i lock relativi al file cui
 esso faceva riferimento, anche se questi fossero stati creati usando altri
 file descriptor che restano aperti.
 
index 06bc957..9c682f7 100644 (file)
--- a/intro.tex
+++ b/intro.tex
@@ -52,13 +52,13 @@ all'hardware, mentre i programmi normali vengono eseguiti in modalit
 (e non possono accedere direttamente alle zone di memoria riservate o alle
 porte di input/output).
 
-Una parte del kernel, lo \textit{scheduler}, si occupa di stabilire, ad
-intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale
-``processo'' deve essere posto in esecuzione (il cosiddetto \textit{preemptive
-  scheduling}\index{preemptive scheduling}). Questo verrà comunque eseguito in
-modalità protetta; quando necessario il processo potrà accedere alle risorse
-hardware soltanto attraverso delle opportune chiamate al sistema che
-restituiranno il controllo al kernel.
+Una parte del kernel, lo \textit{scheduler}\index{scheduler}, si occupa di
+stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle
+priorità, quale ``processo'' deve essere posto in esecuzione (il cosiddetto
+\textit{preemptive scheduling}\index{preemptive scheduling}). Questo verrà
+comunque eseguito in modalità protetta; quando necessario il processo potrà
+accedere alle risorse hardware soltanto attraverso delle opportune chiamate al
+sistema che restituiranno il controllo al kernel.
 
 La memoria viene sempre gestita dal kernel attraverso il meccanismo della
 \textsl{memoria virtuale}\index{memoria virtuale}, che consente di assegnare a
diff --git a/ipc.tex b/ipc.tex
index da8d85a..f06dfbf 100644 (file)
--- a/ipc.tex
+++ b/ipc.tex
@@ -830,7 +830,7 @@ descriptor connessi fra di loro (tramite un socket, appunto), senza dover
 ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
 analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
 differenza è che in questo caso il flusso dei dati può essere effettuato in
-emtrambe le direzioni. Il prototipo della funzione è:
+entrambe le direzioni. Il prototipo della funzione è:
 \begin{functions}
   \headdecl{sys/types.h} 
   \headdecl{sys/socket.h} 
@@ -903,7 +903,7 @@ file, un contatore del numero di riferimenti che ne indichi l'essere in uso,
 essi possono essere cancellati anche se ci sono dei processi che li stanno
 utilizzando, con tutte le conseguenze (negative) del caso.
 
-Un'ulteriore caratterestica negativa è che gli oggetti usati nel System V IPC
+Un'ulteriore caratteristica negativa è che gli oggetti usati nel System V IPC
 vengono creati direttamente dal kernel, e sono accessibili solo specificando
 il relativo \textsl{identificatore}. Questo è un numero progressivo (un po'
 come il \acr{pid} dei processi) che il kernel assegna a ciascuno di essi
@@ -1716,13 +1716,13 @@ void HandSIGTERM(int signo) {
 \end{figure}
 
 In \figref{fig:ipc_mq_fortune_server} si è riportato un estratto delle parti
-primcipali del codice del nuovo server (il codice completo è nel file
+principali del codice del nuovo server (il codice completo è nel file
 \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un
 uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi
 per permettere una comunicazione indipendente fra il server ed i vari client,
 usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile
 in quanto, al contrario di una fifo, la lettura di una coda di messaggi può
-non essere sequanziale, proprio grazie alla classificazione dei messaggi sulla
+non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla
 base del loro tipo.
 
 Il programma, oltre alle solite variabili per il nome del file da cui leggere
@@ -1752,7 +1752,7 @@ Finita la fase di inizializzazione il server esegue in permanenza il ciclo
 principale (\texttt{\small 32--41}). Questo inizia (\texttt{\small 33}) con il
 porsi in attesa di un messaggio di richiesta da parte di un client; si noti
 infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1:
-questo è il valore usato per le richieste dato che corriponde al \acr{pid} di
+questo è il valore usato per le richieste dato che corrisponde al \acr{pid} di
 \cmd{init}, che non può essere un client. L'uso del flag \macro{MSG\_NOERROR}
 è solo per sicurezza, dato che i messaggi di richiesta sono di dimensione
 fissa (e contengono solo il \acr{pid} del client).
@@ -1820,7 +1820,7 @@ non viene chiamata con il flag di creazione in quanto la coda deve essere
 preesistente. In caso di errore (ad esempio se il server non è stato avviato)
 il programma termina immediatamente. 
 
-Una volta acquistito l'identificatore della coda il client compone il
+Una volta acquisito l'identificatore della coda il client compone il
 messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1
 per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server.
 Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad
@@ -1832,7 +1832,7 @@ tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo
 passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il
 messaggio ricevuto.
  
-Benché funzionante questa archietettura risente dello stesso inconveniente
+Benché funzionante questa architettura risente dello stesso inconveniente
 visto anche nel caso del precedente server basato sulle fifo; se il client
 viene interrotto dopo l'invio del messaggio di richiesta e prima della lettura
 della risposta, quest'ultima resta nella coda (così come per le fifo si aveva
@@ -2001,7 +2001,7 @@ struct sem {
   \label{fig:ipc_sem}
 \end{figure}
 
-I dati mentenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
+I dati mantenuti nella struttura, ed elencati in \figref{fig:ipc_sem},
 indicano rispettivamente: 
 \begin{description*}
 \item[\var{semval}] il valore numerico del semaforo.
@@ -2364,14 +2364,14 @@ Alla creazione di un nuovo insieme viene allocata una nuova strutture
 \var{semid\_ds} ed il relativo vettore di strutture \var{sem}. Quando si
 richiede una operazione viene anzitutto verificato che tutte le operazioni
 possono avere successo; se una di esse comporta il blocco del processo il
-kernel creaa una struttura \var{sem\_queue} che viene aggiunta in fondo alla
+kernel crea una struttura \var{sem\_queue} che viene aggiunta in fondo alla
 coda di attesa associata a ciascun insieme di semafori\footnote{che viene
   referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last}
   di \var{semid\_ds}.}. Nella struttura viene memorizzato il riferimento alle
 operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
 struttura \var{sembuf}) e al processo corrente (nel campo \var{sleeper}) poi
-quest'ultimo viene messo stato di attesa e viene invocato lo scheduler per
-passare all'esecuzione di un altro processo.
+quest'ultimo viene messo stato di attesa e viene invocato lo
+scheduler\index{scheduler} per passare all'esecuzione di un altro processo.
 
 Se invece tutte le operazioni possono avere successo queste vengono eseguite
 immediatamente, dopo di che il kernel esegue una scansione della coda di
index 48af070..4bb15c6 100644 (file)
@@ -132,21 +132,22 @@ riprese), 
 \end{figure}
 
 
-Come accennato in \secref{sec:intro_unix_struct} è lo \textit{scheduler} che
-decide quale processo mettere in esecuzione; esso viene eseguito ad ogni
-system call ed ad ogni interrupt,\footnote{più in una serie di altre
-  occasioni. NDT completare questa parte.} (ma può essere anche attivato
-esplicitamente). Il timer di sistema provvede comunque a che esso sia invocato
-periodicamente, generando un interrupt periodico secondo la frequenza
-specificata dalla costante \macro{HZ}, definita in \file{asm/param.h}, ed il
-cui valore è espresso in Hertz.\footnote{Il valore usuale di questa costante è
-  100, per tutte le architetture eccetto l'alpha, per la quale è 1000. Occorre
-  fare attenzione a non confondere questo valore con quello dei clock tick
-  (vedi \secref{sec:sys_unix_time}).}
+Come accennato in \secref{sec:intro_unix_struct} è lo
+\textit{scheduler}\index{scheduler} che decide quale processo mettere in
+esecuzione; esso viene eseguito ad ogni system call ed ad ogni
+interrupt,\footnote{più in una serie di altre occasioni. NDT completare questa
+  parte.} (ma può essere anche attivato esplicitamente). Il timer di sistema
+provvede comunque a che esso sia invocato periodicamente, generando un
+interrupt periodico secondo la frequenza specificata dalla costante
+\macro{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in
+Hertz.\footnote{Il valore usuale di questa costante è 100, per tutte le
+  architetture eccetto l'alpha, per la quale è 1000. Occorre fare attenzione a
+  non confondere questo valore con quello dei clock tick (vedi
+  \secref{sec:sys_unix_time}).}
 %Si ha cioè un interrupt dal timer ogni centesimo di secondo.
 
-Ogni volta che viene eseguito, lo \textit{scheduler} effettua il calcolo delle
-priorità dei vari processi attivi (torneremo su questo in
+Ogni volta che viene eseguito, lo \textit{scheduler}\index{scheduler} effettua
+il calcolo delle priorità dei vari processi attivi (torneremo su questo in
 \secref{sec:proc_priority}) e stabilisce quale di essi debba essere posto in
 esecuzione fino alla successiva invocazione.
 
@@ -459,15 +460,15 @@ Go to next child
 Esaminiamo questo risultato: una prima conclusione che si può trarre è che non
 si può dire quale processo fra il padre ed il figlio venga eseguito per
 primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
-  scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
-  mantenere la portabilità è opportuno non fare comunque affidamento su questo
-  comportamento.} dopo la chiamata a \func{fork}; dall'esempio si può notare
-infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
-stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
-figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
-all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
-mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
-e poi il padre.
+  scheduler\index{scheduler} di Ingo Molnar che esegue sempre per primo il
+  figlio; per mantenere la portabilità è opportuno non fare comunque
+  affidamento su questo comportamento.} dopo la chiamata a \func{fork};
+dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito
+per primo il padre (con la stampa del \acr{pid} del nuovo processo) per poi
+passare all'esecuzione del figlio (completata con i due avvisi di esecuzione
+ed uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
+ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
+(fino alla conclusione) e poi il padre.
 
 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
 scheduling usato dal kernel, dalla particolare situazione in si trova la
@@ -1837,9 +1838,10 @@ quando si definisce \macro{\_POSIX\_SOURCE} o si compila con il flag
 \label{sec:proc_priority}
 
 In questa sezione tratteremo più approfonditamente i meccanismi con il quale
-lo \textit{scheduler} assegna la CPU ai vari processi attivi. In particolare
-prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del
-tempo di CPU, ed illustreremo le varie funzioni di gestione.
+lo \textit{scheduler}\index{scheduler} assegna la CPU ai vari processi attivi.
+In particolare prenderemo in esame i vari meccanismi con cui viene gestita
+l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di
+gestione.
 
 
 \subsection{I meccanismi di \textit{scheduling}}
@@ -1857,8 +1859,8 @@ contrario di altri sistemi (che usano invece il cosiddetto \textit{cooperative
   multitasking}) non sono i singoli processi, ma il kernel stesso a decidere
 quando la CPU deve essere passata ad un altro processo. Come accennato in
 \secref{sec:proc_hierarchy} questa scelta viene eseguita da una sezione
-apposita del kernel, lo \textit{scheduler}, il cui scopo è quello di
-distribuire al meglio il tempo di CPU fra i vari processi.
+apposita del kernel, lo \textit{scheduler}\index{scheduler}, il cui scopo è
+quello di distribuire al meglio il tempo di CPU fra i vari processi.
 
 La cosa è resa ancora più complicata dal fatto che con le architetture
 multi-processore si deve anche scegliere quale sia la CPU più opportuna da
@@ -1986,16 +1988,17 @@ viene assegnato ad un altro campo della struttura (\var{counter}) quando il
 processo viene eseguito per la prima volta e diminuito progressivamente ad
 ogni interruzione del timer.
 
-Quando lo scheduler viene eseguito scandisce la coda dei processi in stato
-\textit{runnable} associando, sulla base del valore di \var{counter}, un peso
-a ciascun processo in attesa di esecuzione,\footnote{il calcolo del peso in
-  realtà è un po' più complicato, ad esempio nei sistemi multiprocessore viene
-  favorito un processo che è eseguito sulla stessa CPU, e a parità del valore
-  di \var{counter} viene favorito chi ha una priorità più elevata.} chi ha il
-peso più alto verrà posto in esecuzione, ed il precedente processo sarà
-spostato in fondo alla coda.  Dato che ad ogni interruzione del timer il
-valore di \var{counter} del processo corrente viene diminuito, questo assicura
-che anche i processi con priorità più bassa verranno messi in esecuzione.
+Quando lo scheduler\index{scheduler} viene eseguito scandisce la coda dei
+processi in stato \textit{runnable} associando, sulla base del valore di
+\var{counter}, un peso a ciascun processo in attesa di esecuzione,\footnote{il
+  calcolo del peso in realtà è un po' più complicato, ad esempio nei sistemi
+  multiprocessore viene favorito un processo che è eseguito sulla stessa CPU,
+  e a parità del valore di \var{counter} viene favorito chi ha una priorità
+  più elevata.} chi ha il peso più alto verrà posto in esecuzione, ed il
+precedente processo sarà spostato in fondo alla coda.  Dato che ad ogni
+interruzione del timer il valore di \var{counter} del processo corrente viene
+diminuito, questo assicura che anche i processi con priorità più bassa
+verranno messi in esecuzione.
 
 La priorità di un processo è così controllata attraverso il valore di
 \var{nice}, che stabilisce la durata della \textit{time-slice}; per il
@@ -2138,11 +2141,11 @@ quando si lavora con processi che usano priorit
 shell cui si sia assegnata la massima priorità assoluta, in modo da poter
 essere comunque in grado di rientrare nel sistema.
 
-Quando c'è un processo con priorità assoluta lo scheduler lo metterà in
-esecuzione prima di ogni processo normale. In caso di più processi sarà
-eseguito per primo quello con priorità assoluta più alta. Quando ci sono più
-processi con la stessa priorità assoluta questi vengono tenuti in una coda
-tocca al kernel decidere quale deve essere eseguito. 
+Quando c'è un processo con priorità assoluta lo scheduler\index{scheduler} lo
+metterà in esecuzione prima di ogni processo normale. In caso di più processi
+sarà eseguito per primo quello con priorità assoluta più alta. Quando ci sono
+più processi con la stessa priorità assoluta questi vengono tenuti in una coda
+tocca al kernel decidere quale deve essere eseguito.
 
 Il meccanismo con cui vengono gestiti questi processi dipende dalla politica
 di scheduling che si è scelto; lo standard ne prevede due:
index 48d45b3..7cbda4f 100644 (file)
@@ -140,9 +140,9 @@ Si dice che il segnale viene \textsl{consegnato} al processo (dall'inglese
 \textit{delivered}) quando viene eseguita l'azione per esso prevista, mentre
 per tutto il tempo che passa fra la generazione del segnale e la sua consegna
 esso è detto \textsl{pendente} (o \textit{pending}). In genere questa
-procedura viene effettuata dallo scheduler quando, riprendendo l'esecuzione
-del processo in questione, verifica la presenza del segnale nella
-\var{task\_struct} e mette in esecuzione il gestore.
+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.
 
 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
@@ -211,11 +211,12 @@ verr
 ignorarlo).
 
 Normalmente l'invio al processo che deve ricevere il segnale è immediato ed
-avviene non appena questo viene rimesso in esecuzione dallo scheduler che
-esegue l'azione specificata. Questo a meno che il segnale in questione non sia
-stato bloccato prima della notifica, nel qual caso l'invio non avviene ed il
-segnale resta \textsl{pendente} indefinitamente. Quando lo si sblocca il
-segnale \textsl{pendente} sarà subito notificato.
+avviene non appena questo viene rimesso in esecuzione dallo
+scheduler\index{scheduler} che esegue l'azione specificata. Questo a meno che
+il segnale in questione non sia stato bloccato prima della notifica, nel qual
+caso l'invio non avviene ed il segnale resta \textsl{pendente}
+indefinitamente. Quando lo si sblocca il segnale \textsl{pendente} sarà subito
+notificato.
 
 Si ricordi però che se l'azione specificata per un segnale è quella di essere
 ignorato questo sarà scartato immediatamente al momento della sua generazione,
@@ -1347,11 +1348,11 @@ Chiaramente, anche se il tempo pu
 nanosecondo, la precisione di \func{nanosleep} è determinata dalla risoluzione
 temporale del timer di sistema. Perciò la funzione attenderà comunque il tempo
 specificato, ma prima che il processo possa tornare ad essere eseguito
-occorrerà almeno attendere il successivo giro di scheduler e cioè un tempo che
-a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre che il sistema
-sia scarico ed il processa venga immediatamente rimesso in esecuzione); per
-questo motivo il valore restituito in \param{rem} è sempre arrotondato al
-multiplo successivo di 1/\macro{HZ}.
+occorrerà almeno attendere il successivo giro di scheduler\index{scheduler} e
+cioè un tempo che a seconda dei casi può arrivare fino a 1/\macro{HZ}, (sempre
+che il sistema sia scarico ed il processa venga immediatamente rimesso in
+esecuzione); per questo motivo il valore restituito in \param{rem} è sempre
+arrotondato al multiplo successivo di 1/\macro{HZ}.
 
 In realtà è possibile ottenere anche pause più precise del centesimo di
 secondo usando politiche di scheduling real time come \macro{SCHED\_FIFO} o