\hline
\macro{NAME\_MAX}& 14 & lunghezza in byte di un nome di file. \\
\macro{PATH\_MAX}& 256 & lunghezza in byte di pathname.\\
- \macro{PIPE\_BUF}& 512 & byte scrivibili atomicamente in una pipe\\
+ \macro{PIPE\_BUF}&4096 & byte scrivibili atomicamente in una pipe\\
\macro{LINK\_MAX} &8 & numero massimo di link a un file\\
\macro{MAX\_CANON}&255 & spazio disponibile nella coda di input
canonica del terminale\\
user space, e quello impiegato dal kernel nelle system call eseguite per conto
del processo.
-Gli altri tre campi servono a quantificare l'uso della memoria virtuale e
-corrispondono rispettivamente al numero di \textit{page fault}\index{page
- fault} (vedi \secref{sec:proc_mem_gen}) avvenuti senza richiedere I/O (i
-cosiddetti \textit{minor page fault}), a quelli che invece han richiesto I/O
-(detti invece \textit{major page fault}) ed al numero di volte che il processo
-è stato completamente tolto dalla memoria per essere inserito nello swap.
+Gli altri tre campi servono a quantificare l'uso della memoria
+virtuale\index{memoria virtuale} e corrispondono rispettivamente al numero di
+\textit{page fault}\index{page fault} (vedi \secref{sec:proc_mem_gen})
+avvenuti senza richiedere I/O (i cosiddetti \textit{minor page fault}), a
+quelli che invece han richiesto I/O (detti invece \textit{major page fault})
+ed al numero di volte che il processo è stato completamente tolto dalla
+memoria per essere inserito nello swap.
In genere includere esplicitamente \file{<sys/time.h>} non è più necessario,
ma aumenta la portabilità, e serve comunque quando, come nella maggior parte
La gestione della memoria è già stata affrontata in dettaglio in
\secref{sec:proc_memory}; abbiamo visto allora che il kernel provvede il
-meccanismo della memoria virtuale attraverso la divisione della memoria fisica
-in pagine.
+meccanismo della memoria virtuale\index{memoria virtuale} attraverso la
+divisione della memoria fisica in pagine.
In genere questo è del tutto trasparente al singolo processo, ma in certi
-casi, come per l'I/O mappato in memoria (vedi \ref{sec:file_memory_map}) che
-usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
+casi, come per l'I/O mappato in memoria (vedi \secref{sec:file_memory_map})
+che usa lo stesso meccanismo per accedere ai file, è necessario conoscere le
dimensioni delle pagine usate dal kernel. Lo stesso vale quando si vuole
gestire in maniera ottimale l'interazione della memoria allocata con il
meccanismo della paginazione.
utilizzare una funzione.
In genere questa dimensione può essere ottenuta attraverso una chiamata a
-\func{sysconf} come \func{sysconf(\_SC\_PAGESIZE)}, ma in BSD 4.2 è stata
+\func{sysconf} come \code{sysconf(\_SC\_PAGESIZE)}, ma in BSD 4.2 è stata
introdotta una apposita funzione, \func{getpagesize}, che restituisce la
dimensione delle pagine di memoria; il suo prototipo è:
\begin{prototype}{unistd.h}{int getpagesize(void)}
\noindent ed il suo comportamento è identico a quello di \func{error} se non
per il fatto che, separati con il solito due punti-spazio, vengono inseriti un
nome di file indicato da \param{fname} ed un numero di linea subito dopo la
-stampa del nome del programma.
+stampa del nome del programma. Inoltre essa usa un'altra variabile globale,
+\var{error\_one\_per\_line}, che settata ad un valore diverso da zero fa si
+che errori relativi alla stessa linea non vengano ripetuti.