From 17bae834f41549575a11ddf444d97de8d575269e Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Tue, 17 Feb 2004 00:32:08 +0000 Subject: [PATCH] Una lunga serie di modifiche per tenere conto della riorganizzazione della parte sulla gestione avanzata dei file --- ChangeLog | 5 ++ fileadv.tex | 164 +++++++++++++++++++++++++++++---------------------- fileunix.tex | 151 +++++++++++++++++++++++++++++------------------ intro.tex | 14 ++--- process.tex | 26 ++++---- prochand.tex | 8 +-- signal.tex | 16 ++--- tcpsock.tex | 8 +-- 8 files changed, 227 insertions(+), 165 deletions(-) diff --git a/ChangeLog b/ChangeLog index 242c92d..76c1bca 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2004-01-13 Simone Piccardi + + * intro.tex: Varie correzioni di ortografia e sintassi da parte di + Massimo Fidanza. + 2003-12-31 Simone Piccardi * tcpsock.tex: Corretto su segnalazione di Enzo. diff --git a/fileadv.tex b/fileadv.tex index f343a48..2d000d8 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -32,18 +32,18 @@ ed analizzeremo le varie funzioni usate per implementare questa modalit I/O. -\subsection{La problematica dell'\textit{I/O multiplexing} e l'uso - dell'\textsl{I/O non-bloccante}} +\subsection{La problematica dell'\textit{I/O multiplexing}} \label{sec:file_noblocking} Abbiamo visto in \secref{sec:sig_gen_beha}, affrontando la suddivisione fra -\textit{fast} e \textit{slow} system call, che in certi casi le funzioni di -I/O possono bloccarsi indefinitamente.\footnote{si ricordi però che questo può - accadere solo per le pipe, i socket\index{socket} ed alcuni file di - dispositivo\index{file!di dispositivo}; sui file normali le funzioni di - lettura e scrittura ritornano sempre subito.} Ad esempio le operazioni di -lettura possono bloccarsi quando non ci sono dati disponibili sul descrittore -su cui si sta operando. +\textit{fast} e \textit{slow} system call,\index{system call lente} che in +certi casi le funzioni di I/O possono bloccarsi indefinitamente.\footnote{si + ricordi però che questo può accadere solo per le pipe, i + socket\index{socket} ed alcuni file di dispositivo\index{file!di + dispositivo}; sui file normali le funzioni di lettura e scrittura + ritornano sempre subito.} Ad esempio le operazioni di lettura possono +bloccarsi quando non ci sono dati disponibili sul descrittore su cui si sta +operando. Questo comportamento causa uno dei problemi più comuni che ci si trova ad affrontare nelle operazioni di I/O, che si verifica quando si deve operare con @@ -286,8 +286,8 @@ sotto controllo anche dei file descriptor con \func{select}, in questo caso si può fare conto sul fatto che all'arrivo di un segnale essa verrebbe interrotta e si potrebbero eseguire di conseguenza le operazioni relative al segnale e alla gestione dati con un ciclo del tipo: -\includecodesnip{listati/select_race.c} -qui però emerge una race condition, perché se il segnale arriva prima della +\includecodesnip{listati/select_race.c} qui però emerge una race +condition,\index{race condition} perché se il segnale arriva prima della chiamata a \func{select}, questa non verrà interrotta, e la ricezione del segnale non sarà rilevata. @@ -407,7 +407,7 @@ compatibilit presente in Linux, e non hanno nulla a che fare con i file \textit{stream} delle librerie standard del C.} è da questi che derivano i nomi di alcune costanti, in quanto per essi sono definite tre classi di dati: -\textsl{normali}, \textit{prioritari} ed \textit{urgenti}.} In Linux la +\textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In Linux la distinzione ha senso solo per i dati \textit{out-of-band} dei socket (vedi \secref{sec:TCP_urgent_data}), ma su questo e su come \func{poll} reagisce alle varie condizioni dei socket torneremo in \secref{sec:TCP_serv_poll}, dove @@ -433,27 +433,21 @@ tramite \var{errno}. %da fare -\section{Altre modalità e funzioni di I/O avanzato} -\label{sec:file_advanced_io} +\section{L'accesso \textsl{asincrono} ai file} +\label{sec:file_asyncronous_access} Benché l'\textit{I/O multiplexing} sia stata la prima, e sia tutt'ora una fra -le più diffuse modalità di gestire l'I/O in situazioni complesse che -coivolgono molti file, esistono altre modalità di gestione delle stesse -problematiche, oltre che differenti interfacce per la gestione di altre -problematiche avanzate riguardanti l'I/O su file, tratteremo tutto ciò in -questa sezione. - +le più diffuse modalità di gestire l'I/O in situazioni complesse in cui si +debba operare su più file contemporaneamente, esistono altre modalità di +gestione delle stesse problematiche. In particolare sono importanti in questo +contesto le modalità di accesso ai file eseguibili in maniera +\textsl{asincrona}, senza cioè che un processo debba bloccarsi, ed utilizzi +invece un meccanismo di notifica asincrono, come un segnale, per rilevare la +possibilità di eseguire le operazioni volute. -\subsection{L'apertura asincrona dei file} -\label{sec:file_asyncronous_open} -Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione -dell'I/O simultaneo su molti file, è costituita dal cosiddetto \textsl{I/O - asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni -di I/O non attendono il completamento delle operazioni prima di ritornare, -così che il processo non viene bloccato. In questo modo diventa ad esempio -possibile effettuare una richiesta preventiva di dati, in modo da poter -effettuare in contemporanea le operazioni di calcolo e quelle di I/O. +\subsection{Operazioni asincrone sui file} +\label{sec:file_asyncronous_operation} Abbiamo accennato in \secref{sec:file_open} che è possibile, attraverso l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei @@ -463,16 +457,21 @@ attivare in un secondo tempo questa modalit l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi \secref{sec:file_fcntl}). -In realtà in questo caso non si tratta di I/O asincrono vero e proprio (che -vedremo in \secref{sec:file_asyncronous_io}), quanto di un meccanismo -asincrono di notifica delle variazione dello stato del file descriptor; quello -che succede è che il sistema genera un segnale (normalmente \const{SIGIO}, ma -è possibile usarne altri) tutte le volte che diventa possibile leggere o -scrivere dal file descriptor che si è posto in questa modalità. Si può inoltre -selezionare, con il comando \const{F\_SETOWN} di \func{fcntl}, quale processo -(o gruppo di processi) riceverà il segnale. Se pertanto si effettuano le -operazioni in risposta alla ricezione del segnale non ci sarà più la necessità -di restare bloccati in attesa della disponibilità di accesso ai file. +In realtà in questo caso non si tratta di eseguire delle operazioni di lettura +o scrittura del file in modo asincrono (tratteremo questo, che più +propriamente è detto \textsl{I/O asincrono} in +\secref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di +notifica delle variazione dello stato del file descriptor aperto in questo +modo. + +Quello che succede è che il sistema genera un segnale (normalmente +\const{SIGIO}, ma è possibile usarne altri con il comando \const{F\_SETSIG} di +\func{fcntl}) tutte le volte che diventa possibile leggere o scrivere dal file +descriptor che si è posto in questa modalità. Si può inoltre selezionare, con +il comando \const{F\_SETOWN} di \func{fcntl}, quale processo (o gruppo di +processi) riceverà il segnale. Se pertanto si effettuano le operazioni in +risposta alla ricezione del segnale non ci sarà più la necessità di restare +bloccati in attesa della disponibilità di accesso ai file. In questo modo si può evitare l'uso delle funzioni \func{poll} o \func{select} che, quando vengono usate con un numero molto grande di file descriptor, non @@ -483,19 +482,22 @@ tenuti sotto controllo per determinare quali di essi (in genere una piccola percentuale) sono diventati attivi. Tuttavia con l'implementazione classica dei segnali questa modalità di I/O -presenta notevoli problemi, dato che non è possibile determinare, quando sono -più di uno, qual'è il file descriptor responsabile dell'emissione del segnale. -Linux però supporta le estensioni POSIX.1b dei segnali che permettono di -superare il problema facendo ricorso alle informazioni aggiuntive restituite -attraverso la struttura \struct{siginfo\_t}, utilizzando la forma estesa -\var{sa\_sigaction} del gestore (si riveda quanto illustrato in +presenta notevoli problemi, dato che non è possibile determinare, quando i +file descriptor sono più di uno, qual'è quello responsabile dell'emissione del +segnale; inoltre dato che i segnali normali non si accumulano, in presenza di +più file descriptor attivi contemporaneamente, più segnali emessi nello stesso +tempo verrebbero notificati una volta sola. Linux però supporta le estensioni +POSIX.1b dei segnali real-time, che possono accumularsi e che permettono di +riconoscere il file descriptor facendo ricorso alle informazioni aggiuntive +restituite attraverso la struttura \struct{siginfo\_t}, utilizzando la forma +estesa \var{sa\_sigaction} del gestore (si riveda quanto illustrato in \secref{sec:sig_sigaction}). Per far questo però occorre utilizzare le funzionalità dei segnali real-time (vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando \const{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di I/O asincrono (il segnale predefinito è \const{SIGIO}). In questo caso il -gestore tutte le volte che riceverà \const{SI\_SIGIO} come valore del +gestore, tutte le volte che riceverà \const{SI\_SIGIO} come valore del campo \var{si\_code}\footnote{il valore resta \const{SI\_SIGIO} qualunque sia il segnale che si è associato all'I/O asincrono, ed indica appunto che il segnale è stato generato a causa di attività nell'I/O asincrono.} di @@ -511,20 +513,30 @@ come \func{poll} e \func{select}, almeno fintanto che non si satura la coda; si eccedono le dimensioni di quest'ultima; in tal caso infatti il kernel, non potendo più assicurare il comportamento corretto per un segnale real-time, invierà al suo posto un \const{SIGIO}, su cui si accumuleranno tutti i segnali -in eccesso, e si dovrà determinare al solito modo quali sono i file diventati +in eccesso, e si dovrà determinare con un ciclo quali sono i file diventati attivi. + \subsection{L'interfaccia POSIX per l'I/O asincrono} \label{sec:file_asyncronous_io} +Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione +dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O + asincrono}. Il concetto base dell'\textsl{I/O asincrono} è che le funzioni +di I/O non attendono il completamento delle operazioni prima di ritornare, +così che il processo non viene bloccato. In questo modo diventa ad esempio +possibile effettuare una richiesta preventiva di dati, in modo da poter +effettuare in contemporanea le operazioni di calcolo e quelle di I/O. + Benché la modalità di apertura asincrona di un file possa risultare utile in varie occasioni (in particolar modo con i socket\index{socket} e gli altri -file per i quali le funzioni di I/O sono system call lente), essa è comunque -limitata alla notifica della disponibilità del file descriptor per le -operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo -standard POSIX.1b definisce anche una interfaccia apposita per l'I/O -asincrono, che prevede un insieme di funzioni dedicate, completamente separate -rispetto a quelle usate normalmente. +file per i quali le funzioni di I/O sono \index{system call lente}system call +lente), essa è comunque limitata alla notifica della disponibilità del file +descriptor per le operazioni di I/O, e non ad uno svolgimento asincrono delle +medesime. Lo standard POSIX.1b definisce una interfaccia apposita per l'I/O +asincrono vero e proprio, che prevede un insieme di funzioni dedicate per la +lettura e la scrittura dei file, completamente separate rispetto a quelle +usate normalmente. In generale questa interfaccia è completamente astratta e può essere implementata sia direttamente nel kernel, che in user space attraverso l'uso @@ -864,6 +876,16 @@ la notifica del completamento di tutte le richieste, impostando l'argomento di \struct{aiocb}. +\section{Altre modalità di I/O avanzato} +\label{sec:file_advanced_io} + +Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O + asincrono}, esistono altre funzioni che implementano delle modalità di +accesso ai file più evolute rispetto alle normali funzioni di lettura e +scrittura che abbiamo esaminato in \secref{sec:file_base_func}. In questa +sezione allora prenderemo in esame le interfacce per l'\textsl{I/O + vettorizzato} e per l'\textsl{I/O mappato in memoria}. + \subsection{I/O vettorizzato} \label{sec:file_multiple_io} @@ -950,9 +972,9 @@ file in una sezione dello spazio di indirizzi del processo. Il meccanismo illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene riportata direttamente nello spazio degli indirizzi del programma. Tutte le operazioni su questa zona verranno riportate indietro sul file dal meccanismo -della memoria virtuale che trasferirà il contenuto di quel segmento sul file -invece che nella swap, per cui si può parlare tanto di file mappato in -memoria, quanto di memoria mappata su file. +della memoria virtuale\index{memoria virtuale} che trasferirà il contenuto di +quel segmento sul file invece che nella swap, per cui si può parlare tanto di +file mappato in memoria, quanto di memoria mappata su file. \begin{figure}[htb] \centering @@ -971,16 +993,16 @@ memoria solo le parti del file che sono effettivamente usate ad un dato istante. Infatti, dato che l'accesso è fatto direttamente attraverso la memoria -virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta -o scritta sul file una pagina alla volta e solo per le parti effettivamente -usate, il tutto in maniera completamente trasparente al processo; l'accesso -alle pagine non ancora caricate avverrà allo stesso modo con cui vengono -caricate in memoria le pagine che sono state salvate sullo swap. Infine in -situazioni in cui la memoria è scarsa, le pagine che mappano un file vengono -salvate automaticamente, così come le pagine dei programmi vengono scritte -sulla swap; questo consente di accedere ai file su dimensioni il cui solo -limite è quello dello spazio di indirizzi disponibile, e non della memoria su -cui possono esserne lette delle porzioni. +virtuale,\index{memoria virtuale} la sezione di memoria mappata su cui si +opera sarà a sua volta letta o scritta sul file una pagina alla volta e solo +per le parti effettivamente usate, il tutto in maniera completamente +trasparente al processo; l'accesso alle pagine non ancora caricate avverrà +allo stesso modo con cui vengono caricate in memoria le pagine che sono state +salvate sullo swap. Infine in situazioni in cui la memoria è scarsa, le +pagine che mappano un file vengono salvate automaticamente, così come le +pagine dei programmi vengono scritte sulla swap; questo consente di accedere +ai file su dimensioni il cui solo limite è quello dello spazio di indirizzi +disponibile, e non della memoria su cui possono esserne lette delle porzioni. L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped I/O}, la prima di queste è \funcd{mmap}, che serve ad eseguire la mappatura @@ -1133,11 +1155,11 @@ come maschera binaria ottenuta dall'OR di uno o pi Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere piuttosto complessi, essi si possono comprendere solo tenendo presente che tutto quanto è comunque basato sul basato sul meccanismo della memoria -virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che -se si cerca di scrivere su una zona mappata in sola lettura si avrà -l'emissione di un segnale di violazione di accesso (\const{SIGSEGV}), dato che -i permessi sul segmento di memoria relativo non consentono questo tipo di -accesso. +virtuale.\index{memoria virtuale} Questo comporta allora una serie di +conseguenze. La più ovvia è che se si cerca di scrivere su una zona mappata in +sola lettura si avrà l'emissione di un segnale di violazione di accesso +(\const{SIGSEGV}), dato che i permessi sul segmento di memoria relativo non +consentono questo tipo di accesso. \begin{figure}[!htb] \centering diff --git a/fileunix.tex b/fileunix.tex index 6f9334d..782afc9 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -992,13 +992,13 @@ tutta una serie di operazioni ausiliarie che descriptor, che non riguardano la normale lettura e scrittura di dati, ma la gestione sia delle loro proprietà, che di tutta una serie di ulteriori funzionalità che il kernel può mettere a disposizione.\footnote{ad esempio si - gestiscono con questa funzione l'I/O asincrono (vedi - \secref{sec:file_asyncronous_io}) e il file locking\index{file!locking} - (vedi \secref{sec:file_locking}).} + gestiscono con questa funzione varie modalità di I/O asincrono (vedi + \secref{sec:file_asyncronous_operation}) e il file + locking\index{file!locking} (vedi \secref{sec:file_locking}).} -Per queste operazioni di manipolazione e di controllo su proprietà e -caratteristiche un file descriptor, viene usata la funzione \funcd{fcntl}, il -cui prototipo è: +Per queste operazioni di manipolazione e di controllo delle varie proprietà e +caratteristiche di un file descriptor, viene usata la funzione \funcd{fcntl}, +il cui prototipo è: \begin{functions} \headdecl{unistd.h} \headdecl{fcntl.h} @@ -1017,92 +1017,127 @@ cui prototipo \end{errlist}} \end{functions} -Il comportamento di questa funzione è determinato dal valore del comando -\param{cmd} che le viene fornito; in \secref{sec:file_dup} abbiamo incontrato -un esempio per la duplicazione dei file descriptor, una lista dei possibili -valori è riportata di seguito: + +Il primo argomento della funzione è sempre il numero di file descriptor +\var{fd} su cui si vuole operare. Il comportamento di questa funzione, il +numero e il tipo degli argomenti, il valore di ritorno e gli eventuali errori +sono determinati dal valore dell'argomento \param{cmd} che in sostanza +corrisponde all'esecuzione di un determinato \textsl{comando}; in +\secref{sec:file_dup} abbiamo incontrato un esempio dell'uso di \func{fcntl} +per la duplicazione dei file descriptor, una lista di tutti i possibili valori +per \var{cmd} è riportata di seguito: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{F\_DUPFD}] trova il primo file descriptor disponibile di valore - maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. In caso di - successo ritorna il nuovo file descriptor. Gli errori possibili sono - \errcode{EINVAL} se \param{arg} è negativo o maggiore del massimo consentito - o \errcode{EMFILE} se il processo ha già raggiunto il massimo numero di - descrittori consentito. + maggiore o uguale ad \param{arg} e ne fa una copia di \param{fd}. Ritorna il + nuovo file descriptor in caso di successo e -1 in caso di errore. Gli errori + possibili sono \errcode{EINVAL} se \param{arg} è negativo o maggiore del + massimo consentito o \errcode{EMFILE} se il processo ha già raggiunto il + massimo numero di descrittori consentito. \item[\const{F\_SETFD}] imposta il valore del \textit{file descriptor flag} al valore specificato con \param{arg}. Al momento l'unico bit usato è quello di \textit{close-on-exec}\index{close-on-exec}, identificato dalla costante \const{FD\_CLOEXEC}, che serve a richiedere che il file venga chiuso nella - esecuzione di una \func{exec} (vedi \secref{sec:proc_exec}). + esecuzione di una \func{exec} (vedi \secref{sec:proc_exec}). Ritorna un + valore nullo in caso di successo e -1 in caso di errore. \item[\const{F\_GETFD}] ritorna il valore del \textit{file descriptor flag} di - \param{fd}, se \const{FD\_CLOEXEC} è impostato i file descriptor aperti - vengono chiusi attraverso una \func{exec} altrimenti (il comportamento - predefinito) restano aperti. -\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag}, - permette cioè di rileggere quei bit impostati da \func{open} all'apertura del - file che vengono memorizzati (quelli riportati nella prima e terza sezione - di \tabref{tab:file_open_flags}). + \param{fd} o -1 in caso di errore; se \const{FD\_CLOEXEC} è impostato i file + descriptor aperti vengono chiusi attraverso una \func{exec} altrimenti (il + comportamento predefinito) restano aperti. +\item[\const{F\_GETFL}] ritorna il valore del \textit{file status flag} in + caso di successo o -1 in caso di errore; permette cioè di rileggere quei bit + impostati da \func{open} all'apertura del file che vengono memorizzati + (quelli riportati nella prima e terza sezione di + \tabref{tab:file_open_flags}). \item[\const{F\_SETFL}] imposta il \textit{file status flag} al valore - specificato da \param{arg}, possono essere impostati solo i bit riportati - nella terza sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di - manuale riporta come impostabili solo \const{O\_APPEND}, - \const{O\_NONBLOCK} e \const{O\_ASYNC}.} + specificato da \param{arg}, ritorna un valore nullo in caso di successo o -1 + in caso di errore. Possono essere impostati solo i bit riportati nella terza + sezione di \tabref{tab:file_open_flags}.\footnote{la pagina di manuale + riporta come impostabili solo \const{O\_APPEND}, \const{O\_NONBLOCK} e + \const{O\_ASYNC}.} \item[\const{F\_GETLK}] richiede un controllo sul file lock specificato da - \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato - (questa funzionalità è trattata in dettaglio in - \secref{sec:file_posix_lock}). + \param{lock}, sovrascrivendo la struttura da esso puntata con il risultato, + ritorna un valore nullo in caso di successo o -1 in caso di errore. Questa + funzionalità è trattata in dettaglio in \secref{sec:file_posix_lock}. \item[\const{F\_SETLK}] richiede o rilascia un file lock a seconda di quanto specificato nella struttura puntata da \param{lock}. Se il lock è tenuto da qualcun'altro ritorna immediatamente restituendo -1 e imposta \var{errno} a - \errcode{EACCES} o \errcode{EAGAIN} (questa funzionalità è trattata in - dettaglio in \secref{sec:file_posix_lock}). + \errcode{EACCES} o \errcode{EAGAIN}, in caso di successo ritorna un valore + nullo. Questa funzionalità è trattata in dettaglio in + \secref{sec:file_posix_lock}. \item[\const{F\_SETLKW}] identica a \const{F\_SETLK} eccetto per il fatto che la funzione non ritorna subito ma attende che il blocco sia rilasciato. Se l'attesa viene interrotta da un segnale la funzione restituisce -1 e imposta - \var{errno} a \errcode{EINTR} (questa funzionalità è trattata in dettaglio in - \secref{sec:file_posix_lock}). + \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore nullo. + Questa funzionalità è trattata in dettaglio in \secref{sec:file_posix_lock}. \item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o l'identificatore del process group\footnote{i \texttt{process group} sono - (vedi \secref{sec:sess_proc_group}) sono raggruppamenti di processi usati - nel controllo di sessione; a ciascuno di essi è associato un - identificatore (un numero positivo analogo al \acr{pid}).} che è preposto - alla ricezione dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi - associati al file descriptor \param{fd}. Nel caso di un process group viene - restituito un valore negativo il cui valore assoluto corrisponde - all'identificatore del process group. + (vedi \secref{sec:sess_proc_group}) raggruppamenti di processi usati nel + controllo di sessione; a ciascuno di essi è associato un identificatore + (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione + dei segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file + descriptor \param{fd}. Nel caso di un process group viene restituito un + valore negativo il cui valore assoluto corrisponde all'identificatore del + process group. In caso di errore viene restituito -1. \item[\const{F\_SETOWN}] imposta, con il valore dell'argomento \param{arg}, l'identificatore del processo o del \textit{process group} che riceverà i segnali \const{SIGIO} e \const{SIGURG} per gli eventi associati al file - descriptor \param{fd}. Come per \const{F\_GETOWN}, per impostare un process - group si deve usare per \param{arg} un valore negativo, il cui valore - assoluto corrisponde all'identificatore del process group. + descriptor \param{fd}, ritorna un valore nullo in caso di successo o -1 in + caso di errore. Come per \const{F\_GETOWN}, per impostare un + \textit{process group} si deve usare per \param{arg} un valore negativo, il + cui valore assoluto corrisponde all'identificatore del \textit{process + group}. \item[\const{F\_GETSIG}] restituisce il valore del segnale inviato quando ci sono dati disponibili in ingresso su un file descriptor aperto ed impostato per l'I/O asincrono (si veda \secref{sec:file_asyncronous_io}). Il valore 0 indica il valore predefinito (che è \const{SIGIO}), un valore diverso da zero indica il segnale richiesto, (che può essere anche lo stesso - \const{SIGIO}). + \const{SIGIO}). In caso di errore ritorna -1. \item[\const{F\_SETSIG}] imposta il segnale da inviare quando diventa - possibile effettuare I/O sul file descriptor in caso di I/O asincrono. Il + possibile effettuare I/O sul file descriptor in caso di I/O asincrono, + ritorna un valore nullo in caso di successo o -1 in caso di errore. Il valore zero indica di usare il segnale predefinito, \const{SIGIO}. Un altro - valore (compreso lo stesso \const{SIGIO}) specifica il segnale voluto; l'uso - di un valore diverso da zero permette inoltre, se si è installato il - gestore del segnale come \var{sa\_sigaction} usando + valore diverso da zero (compreso lo stesso \const{SIGIO}) specifica il + segnale voluto; l'uso di un valore diverso da zero permette inoltre, se si è + installato il gestore del segnale come \var{sa\_sigaction} usando \const{SA\_SIGINFO}, (vedi \secref{sec:sig_sigaction}), di rendere - disponibili al gestore informazioni ulteriori informazioni riguardo il - file che ha generato il segnale attraverso i valori restituiti in - \struct{siginfo\_t} (come vedremo in - \secref{sec:file_asyncronous_io}).\footnote{i due comandi \const{F\_SETSIG} - e \const{F\_GETSIG} sono una estensione specifica di Linux.} + disponibili al gestore informazioni ulteriori riguardo il file che ha + generato il segnale attraverso i valori restituiti in \struct{siginfo\_t} + (come vedremo in \secref{sec:file_asyncronous_io}).\footnote{i due comandi + \const{F\_SETSIG} e \const{F\_GETSIG} sono una estensione specifica di + Linux.} +\item[\const{F\_SETLEASE}] imposta o rimuove un \textit{file + lease}\footnote{questa è una nuova funzionalità, specifica di Linux, e + presente solo a partire dai kernel della serie 2.4.x, in cui il processo + che detiene un \textit{lease} su un file riceve una notifica qualora un + altro processo cerca di eseguire una \func{open} o una \func{truncate} su + di esso.} sul file descriptor \var{fd} a seconda del valore del terzo + argomento, che in questo caso è un \ctyp{int}, ritorna un valore nullo in + caso di successo o -1 in caso di errore. Questa funzionalità avanzata è + trattata in dettaglio in \secref{sec:file_asyncronous_operation}. +\item[\const{F\_GETLEASE}] restituisce il tipo di \textit{file lease} che il + processo detiene nei confronti del file descriptor \var{fd} o -1 in caso di + errore. Con questo comando il terzo argomento può essere omesso. Questa + funzionalità avanzata è trattata in dettaglio in + \secref{sec:file_asyncronous_operation}. +\item[\const{F\_NOTIFY}] attiva un meccanismo di notifica per cui viene + riportata al processo chiamante, tramite il segnale \const{SIGIO} (o altro + segnale specificato con \const{F\_SETSIG}) ogni modifica eseguita o + direttamente sulla directory cui \var{fd} fa riferimento, o su uno dei file + in essa contenuti; ritorna un valore nullo in caso di successo o -1 in caso + di errore. Questa funzionalità avanzata, disponibile dai kernel della serie + 2.4.x, è trattata in dettaglio in \secref{sec:file_asyncronous_operation}. \end{basedescript} La maggior parte delle funzionalità di \func{fcntl} sono troppo avanzate per -poter essere affrontate in dettaglio a questo punto; saranno riprese più -avanti quando affronteremo le problematiche ad esse relative (in particolare -le tematiche relative all'I/O asincrono sono trattate in maniera esaustiva in -\secref{sec:file_asyncronous_io} mentre quelle relative al \textit{file +poter essere affrontate in tutti i loro aspetti a questo punto; saranno +pertanto riprese più avanti quando affronteremo le problematiche ad esse +relative. In particolare le tematiche relative all'I/O asincrono e ai vari +meccanismi di notifica saranno trattate in maniera esaustiva in +\secref{sec:file_asyncronous_operation} mentre quelle relative al \textit{file locking}\index{file!locking} saranno esaminate in \secref{sec:file_locking}). + Si tenga presente infine che quando si usa la funzione per determinare le modalità di accesso con cui è stato aperto il file (attraverso l'uso del comando \const{F\_GETFL}) è necessario estrarre i bit corrispondenti nel diff --git a/intro.tex b/intro.tex index a7355de..28719d4 100644 --- a/intro.tex +++ b/intro.tex @@ -195,7 +195,7 @@ maggioranza dei casi,\footnote{esistono implementazioni diverse delle librerie dal progetto GNU. Le \textit{libc5} oggi sono, tranne casi particolari, completamente soppiantate dalle \acr{glibc}, le \textit{uClib} pur non essendo complete come le \acr{glibc}, restano invece molto diffuse nel mondo - embedded per le loro di dimensioni ridotte (e soprattutto la possibilità di + embedded per le loro dimensioni ridotte (e soprattutto la possibilità di togliere le parti non necessarie), e pertanto costituiscono un valido rimpiazzo delle \acr{glibc} in tutti quei sistemi specializzati che richiedono una minima occupazione di memoria.} si dovrebbe usare il nome @@ -257,10 +257,10 @@ breve \textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il dall'acronimo \acr{gid}, e sono quelli che vengono usati dal kernel per identificare l'utente. -In questo modo il sistema è in grado di tenere traccia per ogni processo -dell'utente a cui appartiene ed impedire ad altri utenti di interferire con -esso. Inoltre con questo sistema viene anche garantita una forma base di -sicurezza interna in quanto anche l'accesso ai file (vedi +In questo modo il sistema è in grado di tenere traccia dell'utente a cui +appartiene ciascun processo ed impedire ad altri utenti di interferire con +quest'ultimo. Inoltre con questo sistema viene anche garantita una forma base +di sicurezza interna in quanto anche l'accesso ai file (vedi \secref{sec:file_access_control}) è regolato da questo meccanismo di identificazione. @@ -447,7 +447,7 @@ di POSIX.4 come di POSIX.1b). Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione si aggiungono continuamente, mentre le versioni precedenti vengono riviste; -talvolta poi i riferimenti cambiamo nome, per cui anche solo seguire le +talvolta poi i riferimenti cambiano nome, per cui anche solo seguire le denominazioni usate diventa particolarmente faticoso; una pagina dove si possono recuperare varie (e di norma piuttosto intricate) informazioni è: \href{http://www.pasc.org/standing/sd11.html} @@ -664,7 +664,7 @@ Le macro disponibili per i vari standard sono le seguenti: compatibilità prima di quelle normali. \item[\macro{\_SVID\_SOURCE}] definendo questa macro si attivano le funzionalità derivate da SVID. Esse comprendono anche quelle definite negli - standard ISO C, POSIX.1, POSIX.2, and X/Open. + standard ISO C, POSIX.1, POSIX.2, e X/Open. \item[\macro{\_XOPEN\_SOURCE}] definendo questa macro si attivano le funzionalità descritte nella \textit{X/Open Portability Guide}. Anche queste sono un sovrainsieme di quelle definite in POSIX.1 e POSIX.2 ed in effetti diff --git a/process.tex b/process.tex index aeacae8..831c648 100644 --- a/process.tex +++ b/process.tex @@ -173,9 +173,9 @@ pulizia al programmatore che la utilizza. all'utente, avere la possibilità di effettuare automaticamente la chiamata ad una funzione che effettui tali operazioni all'uscita dal programma. A questo scopo lo standard ANSI C prevede la possibilità di registrare un certo numero -funzioni che verranno eseguite all'uscita dal programma (sia per la chiamata -ad \func{exit} che per il ritorno di \func{main}). La prima funzione che si -può utilizzare a tal fine è \funcd{atexit} il cui prototipo è: +di funzioni che verranno eseguite all'uscita dal programma (sia per la +chiamata ad \func{exit} che per il ritorno di \func{main}). La prima funzione +che si può utilizzare a tal fine è \funcd{atexit} il cui prototipo è: \begin{prototype}{stdlib.h}{void atexit(void (*function)(void))} Registra la funzione \param{function} per la chiamata all'uscita dal programma. @@ -185,8 +185,8 @@ pu \end{prototype} \noindent la funzione richiede come argomento l'indirizzo di una opportuna funzione di pulizia da chiamare all'uscita del programma, che non deve -prendere argomenti e non deve ritornare niente (deve essere essere cioè -definita come \code{void function(void)}). +prendere argomenti e non deve ritornare niente (deve essere cioè definita come +\code{void function(void)}). Un'estensione di \func{atexit} è la funzione \funcd{on\_exit}, che le \acr{glibc} includono per compatibilità con SunOS, ma che non è detto sia @@ -1401,7 +1401,7 @@ stack all'indirizzo dove sono stati salvati i parametri, normale pensare di poter effettuare questa operazione. In generale però possono esistere anche realizzazioni diverse, per questo -motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo opaco} +motivo \macro{va\_list} è definito come \textsl{tipo opaco}\index{tipo!opaco} e non può essere assegnato direttamente ad un'altra variabile dello stesso tipo. Per risolvere questo problema lo standard ISO C99\footnote{alcuni sistemi che non hanno questa macro provvedono al suo posto @@ -1584,13 +1584,13 @@ e statiche mantengono i valori che avevano al momento della chiamata di \func{longjmp}, ma quelli delle variabili automatiche (o di quelle dichiarate \direct{register}\footnote{la direttiva \direct{register} del compilatore chiede che la variabile dichiarata tale sia mantenuta, nei limiti del - possibile, all'interno di un registro del processore. Questa direttiva - origina dai primi compilatori, quando stava al programmatore scrivere codice - ottimizzato, riservando esplicitamente alle variabili più usate l'uso dei - registri del processore. Oggi questa direttiva oggi è in disuso dato che - tutti i compilatori sono normalmente in grado di valutare con maggior - efficacia degli stessi programmatori quando sia il caso di eseguire questa - ottimizzazione.}) sono in genere indeterminati. + possibile, all'interno di un registro del processore. Questa direttiva è + originaria dell'epoca dai primi compilatori, quando stava al programmatore + scrivere codice ottimizzato, riservando esplicitamente alle variabili più + usate l'uso dei registri del processore. Oggi questa direttiva è in disuso + dato che tutti i compilatori sono normalmente in grado di valutare con + maggior efficacia degli stessi programmatori quando sia il caso di eseguire + questa ottimizzazione.}) sono in genere indeterminati. Quello che succede infatti è che i valori delle variabili che sono tenute in memoria manterranno il valore avuto al momento della chiamata di diff --git a/prochand.tex b/prochand.tex index 5d62dab..448ad06 100644 --- a/prochand.tex +++ b/prochand.tex @@ -541,11 +541,11 @@ i processi figli. Quello che succede è che quando lo standard output del padre viene rediretto, lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha -la caratteristica di duplicare (allo stesso modo in cui lo fa la funzione -\func{dup}, trattata in \secref{sec:file_dup}) nei figli tutti i file -descriptor aperti nel padre, il che comporta che padre e figli condividono le +la caratteristica di duplicare nei figli tutti i file descriptor aperti nel +padre (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in +\secref{sec:file_dup}), il che comporta che padre e figli condividono le stesse voci della \textit{file table} (per la spiegazione di questi termini si -veda \secref{sec:file_sharing}) e fra cui c'è anche la posizione corrente nel +veda \secref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel file. In questo modo se un processo scrive sul file aggiornerà la posizione corrente diff --git a/signal.tex b/signal.tex index 20c0f90..c426986 100644 --- a/signal.tex +++ b/signal.tex @@ -781,13 +781,13 @@ programmi eseguiti in background, che altrimenti sarebbero interrotti da una successiva pressione di \texttt{C-c} o \texttt{C-y}. Per quanto riguarda il comportamento di tutte le altre system call si danno -sostanzialmente due casi, a seconda che esse siano \textsl{lente} -(\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran parte di esse -appartiene a quest'ultima categoria, che non è influenzata dall'arrivo di un -segnale. Esse sono dette \textsl{veloci} in quanto la loro esecuzione è -sostanzialmente immediata; la risposta al segnale viene sempre data dopo che -la system call è stata completata, in quanto attendere per eseguire un -gestore non comporta nessun inconveniente. +sostanzialmente due casi, a seconda che esse siano\index{system call lente} +\textsl{lente} (\textit{slow}) o \textsl{veloci} (\textit{fast}). La gran +parte di esse appartiene a quest'ultima categoria, che non è influenzata +dall'arrivo di un segnale. Esse sono dette \textsl{veloci} in quanto la loro +esecuzione è sostanzialmente immediata; la risposta al segnale viene sempre +data dopo che la system call è stata completata, in quanto attendere per +eseguire un gestore non comporta nessun inconveniente. In alcuni casi però alcune system call (che per questo motivo vengono chiamate \textsl{lente}) possono bloccarsi indefinitamente. In questo caso non si può @@ -1737,7 +1737,7 @@ in \tabref{tab:sig_sa_flag}. \const{SA\_RESTART} & Riavvia automaticamente le \textit{slow system call} quando vengono interrotte dal suddetto segnale; riproduce cioè il comportamento standard - di BSD.\\ + di BSD.\index{system call lente}\\ \const{SA\_NOMASK} & Evita che il segnale corrente sia bloccato durante l'esecuzione del gestore.\\ \const{SA\_NODEFER} & Sinonimo di \const{SA\_NOMASK}.\\ diff --git a/tcpsock.tex b/tcpsock.tex index 5c618e5..8c50b5e 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -2152,10 +2152,10 @@ perch interrotta dall'arrivo di \const{SIGCHLD}, è quella ad \func{accept}, che è l'unica funzione che può mettere il processo padre in stato di sleep nel periodo in cui un figlio può terminare; si noti infatti come le altre -\textit{slow system call}\footnote{si ricordi la distinzione fatta in - \secref{sec:sig_gen_beha}.} o sono chiamate prima di entrare nel ciclo -principale, quando ancora non esistono processi figli, o sono chiamate dai -figli stessi e non risentono di \const{SIGCHLD}. +\index{system call lente} \textit{slow system call}\footnote{si ricordi la + distinzione fatta in \secref{sec:sig_gen_beha}.} o sono chiamate prima di +entrare nel ciclo principale, quando ancora non esistono processi figli, o +sono chiamate dai figli stessi e non risentono di \const{SIGCHLD}. Per questo l'unica modifica sostanziale nel ciclo principale (\texttt{\small 23--42}), rispetto precedente versione di \figref{fig:TCP_ServEcho_first}, è -- 2.30.2