+La funzione copia direttamente \param{count} byte dal file descriptor
+\param{in\_fd} al file descriptor \param{out\_fd}; in caso di successo
+funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a
+\param{out\_fd} o $-1$ in caso di errore, come le ordinarie \func{read} e
+\func{write} questo valore può essere inferiore a quanto richiesto con
+\param{count}.
+
+Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
+dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
+posizione indicata dal valore puntato da \param{offset}. In questo caso detto
+valore sarà aggiornato, come \textit{value result argument}, per indicare la
+posizione del byte successivo all'ultimo che è stato letto, mentre la
+posizione corrente sul file non sarà modificata. Se invece \param{offset} è
+nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
+letti da \param{in\_fd}.
+
+Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file
+descriptor, e permette di sostituire la invocazione successiva di una
+\func{read} ed una \func{write} (e l'allocazione del relativo buffer) con una
+sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di
+chiamate al sistema e risparmiare in trasferimenti di dati da kernel space a
+user space e viceversa. La massima utilità della funzione si ha comunque per
+il trasferimento di dati da un file su disco ad socket di rete,\footnote{il
+ caso classico del lavoro un server web, ed infatti Apache ha una opzione per
+ il supporto esplicito di questa funzione.} dato che in questo caso diventa
+possibile effettuare il trasferimento diretto via DMA dal controller del disco
+alla scheda di rete, senza neanche allocare un buffer nel kernel.\footnote{il
+ meccanismo è detto \textit{zerocopy} in quanto i dati non vengono mai
+ copiati dal kernel, che si limita a programmare solo le operazioni di
+ lettura e scrittura via DMA.}
+
+Con i kernel della serie 2.6 ci si è accorti però che, a parte quest'ultimo
+caso, l'uso di \func{sendfile} non sempre portava significativi miglioramenti
+delle prestazioni rispetto all'uso in sequenza di \func{read} e \func{write},
+\footnote{nel caso generico infatti il kernel deve comunque allocare un buffer
+ ed effettuare la copia dei dati, e in tal caso spesso il guadagno ottenibile
+ nel ridurre il numero di chiamate al sistema non compensa le ottimizzazioni
+ che possono essere fatte da una applicazione in user space che ha una
+ maggiore conoscenza su come questi sono strutturati.} e che anzi in certi
+casi si avevano dei peggioramenti, questo ha portato alla
+decisione\footnote{per alcune motivazioni di questa scelta si può fare
+ riferimento a quanto illustrato da Linus Torvalds in
+ \href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}
+ {\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}}.}
+di consentire l'uso della funzione soltanto quando il file da cui si legge
+supporta le operazioni di \textit{memory mapping} (vale a dire non è un
+socket) e quello su cui si scrive è un socket; in tutti gli altri casi si avrà
+un errore di \errcode{EINVAL}.
+
+Nonostante i limiti illustrati resta comunque il dubbio se la scelta di
+disabilitare \func{sendfile} per il trasferimento di dati fra file di dati sia
+davvero corretta; la funzione infatti se non altro consentirebbe di
+semplificare l'interfaccia per la copia dei dati, evitando di dover gestire
+l'allocazione di un buffer temporaneo per il loro trasferimento in tutti quei
+casi in cui non c'è necessità di fare controlli sugli stessi. Inoltre essa
+avrebbe comunque il vantaggio di evitare trasferimenti di dati da e verso
+l'user space.
+
+Il dubbio è stato rimosso con l'introduzione della system call
+\func{splice},\footnote{avvenuto a partire dal kernel 2.6.17.} il cui scopo è
+appunto quello di fornire un meccanismo generico per il trasferimento di dati
+da o verso un file utilizzando un buffer intermedio gestito direttamente dal
+kernel. Lo scopo della funzione può sembrare lo stesso di \func{sendfile}, ma
+in realtà esse sono profondamente diverse nel loro meccanismo di
+funzionamento; \func{sendfile} infatti, come accennato, non necessita affatto
+(anzi nel caso di Linux viene sostanzialmente usata solo in questo caso) di
+avere a disposizione un buffer interno, perché esegue un trasferimento diretto
+di dati; questo la rende in generale molto più efficiente, ma anche limitata
+nelle sue applicazioni.
+
+Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
+ realtà la proposta originale di Larry Mc Voy non ne differisce poi tanto,
+ quello che la rende davvero diversa è stata la reinterpretazione che ne è
+ stata fatta nell'implementazione su Linux realizzata da Jens Anxboe, di cui
+ si può trovare un buon riassunto in \href{http://kerneltrap.org/node/6505}
+ {\texttt{http://kerneltrap.org/node/6505}}.} si tratta semplicemente di una
+funzione che consente di fare delle operazioni di trasferimento dati da e
+verso un buffer interamente gestito in kernel space, in maniera del tutto
+generica. In questo caso il cuore della funzione (e delle affini
+\func{vmsplice} e \func{tee}, che tratteremo più avanti) è appunto il buffer
+in kernel space; questo è anche quello che ne ha semplificato
+l'adozione,\footnote{la funzione infatti non è definita in nessuno standard,
+ e, allo stato attuale è disponibile soltanto su Linux.} perché
+l'infrastruttura per la gestione di un buffer in kernel space è presente fin
+dagli albori di Unix per la realizzazione delle \textit{pipe} (tratteremo
+l'argomento in sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale allora
+\func{splice} non è che un'altra interfaccia con cui esporre in userspace
+l'oggetto \textsl{buffer in kernel space}.
+
+Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
+come area di memoria dove appoggiare i dati che vengono trasferiti da un capo
+all'altro della stessa (vedi fig.~\ref{fig:ipc_pipe_singular}) per creare un
+meccanismo di comunicazione fra processi, nel caso di \funcd{splice} il buffer
+viene usato o come fonte dei dati che saranno scritti su un file, o come
+destinazione dei dati che vengono letti da un file. La funzione infatti è una
+interfaccia generica che consente di trasferire dati da un buffer ad un file o
+viceversa; il suo prototipo, accessibile solo avendo definito
+\macro{\_GNU\_SOURCE},\footnote{ovviamente, essendo come detto la funzione
+ totalmente specifica di Linux, essa non è prevista da nessuno standard e
+ deve essere evitata se si vogliono scrivere programmi portabili.} è:
+\begin{functions}
+ \headdecl{fcntl.h}
+
+ \funcdecl{}
+
+ Trasferisce dati da un file verso una pipe o viceversa.
+
+ \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
+ successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
+ dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
+ \param{out\_fd} e la scrittura si bloccherebbe.
+ \item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati
+ (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
+ \param{in\_fd}.
+ \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
+ \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
+ \param{in\_fd}.
+ \end{errlist}
+ ed inoltre \errcode{EBADF} e \errcode{EFAULT}.
+ }
+\end{functions}
projects / gapil.git / blobdiff