\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è valido o non è aperto in lettura.
- \item[\errcode{EINVAL}] \param{fd} si riferisce ad un tipo di file che non
- supporta l'operazione (come una pipe o un socket)..
+ \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+ valido o non è aperto in lettura.
+ \item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
+ file che non supporta l'operazione (come una pipe o un socket).
\end{errlist}
}
\end{functions}
momento (ad esempio in fase di inizializzazione) la lettura, così da ottenere
una migliore risposta nelle operazioni successive.
-Il concetto di \func{readahead} viene generalizzato da
-\funcd{posix\_fadvise},\footnote{al contario di \func{readahead} la funzione è
- definita nello standard POSIX.1-2001 (anche se l'argomento \param{len} è
- stato modificato da \ctyp{size\_t} a \ctyp{off\_t} nella revisione
- POSIX.1-2003 TC5), però è disponibile su Linux a partire dai kernel della
- serie 2.6.} che consente di ``\textsl{avvisare}'' il kernel sulle modalità
-con cui si intende accedere nel futuro ad una certa porzione di un file, così
-che esso possa provvedere le opportune ottimizzazioni; il suo prototipo è:
+Il concetto di \func{readahead} viene generalizzato nello standard
+POSIX.1-2001 dalla funzione \funcd{posix\_fadvise},\footnote{anche se
+ l'argomento \param{len} è stato modificato da \ctyp{size\_t} a \ctyp{off\_t}
+ nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
+kernel sulle modalità con cui si intende accedere nel futuro ad una certa
+porzione di un file,\footnote{la funzione però è stata introdotta su Linux
+ solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
+opportune ottimizzazioni; il suo prototipo, che può è disponibile solo se si
+definisce la macro \macro{\_XOPEN\_SOURCE} ad almeno 600, è:
\begin{functions}
\headdecl{fcntl.h}
\bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è valido o non è aperto in lettura.
- \item[\errcode{EINVAL}] \param{fd} si riferisce ad un tipo di file che non
- supporta l'operazione (come una pipe o un socket)..
+ \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
+ valido.
+ \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
+ \param{fd} si riferisce ad un tipo di file che non supporta l'operazione
+ (come una pipe o un socket).
\end{errlist}
+ \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una pipe o
+ un socket (ma su Linux viene restituito \errcode{EINVAL}).
}
\end{functions}
% http://math.arizona.edu/~swig/documentation/pthreads/
% http://www.humanfactor.com/pthreads/
+Il modello classico dell'esecuzione dei programmi nei sistemi Unix, illustrato
+in sez.~\ref{cha:process_interface}, è fondato sui processi. Il modello nasce
+per assicurare la massima stabilità al sistema e prevede una rigida
+separazione fra i diversi processi, in modo che questi non possano disturbarsi
+a vicenda.
+
+Le applicazioni moderne però sono altamente concorrenti, e necessitano quindi
+di un gran numero di processi; questo ha portato a scontrarsi con alcuni
+limiti dell'architettura precedente. In genere i fautori del modello di
+programmazione a \texttt{thread} sottolineano due problemi connessi all'uso
+dei processi:
+\begin{itemize}
+\item
+\item
+\end{itemize}
+
+
+
\subsection{I \textit{thread} e Linux}
\label{sec:linux_thread}
+
+
+
+
\subsection{Implementazioni alternative}
\label{sec:thread_other}