X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=ipc.tex;h=5841c54bd8a87cf6bc6a21bbaa7b27a0aa90caa1;hb=85590332c245e487cff2b566b2df286acc4289ee;hp=cb30002d1525f2a3e83f798b88eb76bc3625c4b3;hpb=4e1da5b259a86278710be32441de7b88b9287ec1;p=gapil.git

diff --git a/ipc.tex b/ipc.tex
index cb30002..5841c54 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -114,7 +114,7 @@ essere bloccante (qualora non siano presenti dati), inoltre se si legge da una
 pipe il cui capo in scrittura è stato chiuso, si avrà la ricezione di un EOF
 (vale a dire che la funzione \func{read} ritornerà restituendo 0).  Se invece
 si esegue una scrittura su una pipe il cui capo in lettura non è aperto il
-processo riceverà il segnale \const{SIGPIPE}, e la funzione di scrittura
+processo riceverà il segnale \signal{SIGPIPE}, e la funzione di scrittura
 restituirà un errore di \errcode{EPIPE} (al ritorno del gestore, o qualora il
 segnale sia ignorato o bloccato).
 
@@ -418,13 +418,13 @@ o nella relazione padre/figlio; per superare questo problema lo standard
 POSIX.1 ha definito dei nuovi oggetti, le \textit{fifo}, che hanno le stesse
 caratteristiche delle pipe, ma che invece di essere strutture interne del
 kernel, visibili solo attraverso un file descriptor, sono accessibili
-attraverso un \index{inode} inode che risiede sul filesystem, così che i
+attraverso un \itindex{inode} inode che risiede sul filesystem, così che i
 processi le possono usare senza dovere per forza essere in una relazione di
 \textsl{parentela}.
 
 Utilizzando una \textit{fifo} tutti i dati passeranno, come per le pipe,
 attraverso un apposito buffer nel kernel, senza transitare dal filesystem;
-\index{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
+\itindex{inode} l'inode allocato sul filesystem serve infatti solo a fornire un
 punto di riferimento per i processi, che permetta loro di accedere alla stessa
 fifo; il comportamento delle funzioni di lettura e scrittura è identico a
 quello illustrato per le pipe in sez.~\ref{sec:ipc_pipes}.
@@ -707,7 +707,7 @@ complessa e continua ad avere vari inconvenienti\footnote{lo stesso Stevens,
   che esamina questa architettura in \cite{APUE}, nota come sia impossibile
   per il server sapere se un client è andato in crash, con la possibilità di
   far restare le fifo temporanee sul filesystem, di come sia necessario
-  intercettare \const{SIGPIPE} dato che un client può terminare dopo aver
+  intercettare \signal{SIGPIPE} dato che un client può terminare dopo aver
   fatto una richiesta, ma prima che la risposta sia inviata (cosa che nel
   nostro esempio non è stata fatta).}; in generale infatti l'interfaccia delle
 fifo non è adatta a risolvere questo tipo di problemi, che possono essere
@@ -892,7 +892,7 @@ gli 8 bit meno significativi.\footnote{nelle libc4 e libc5, come avviene in
 
 Il problema è che anche così non c'è la sicurezza che il valore della chiave
 sia univoco, infatti esso è costruito combinando il byte di \param{proj\_id)}
-con i 16 bit meno significativi \index{inode} dell'inode del file
+con i 16 bit meno significativi \itindex{inode} dell'inode del file
 \param{pathname} (che vengono ottenuti attraverso \func{stat}, da cui derivano
 i possibili errori), e gli 8 bit meno significativi del numero del dispositivo
 su cui è il file.  Diventa perciò relativamente facile ottenere delle
@@ -947,7 +947,7 @@ il proprietario, il suo gruppo e tutti gli altri.
 
 Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di
 \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati
-rispettivamente al valore dell'user-ID e del group-ID effettivo del processo
+rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo
 che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono
 essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi.
 
@@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza:
 \begin{itemize*}
 \item se il processo ha i privilegi di amministratore l'accesso è sempre
   consentito. 
-\item se l'user-ID effettivo del processo corrisponde o al valore del campo
+\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo
   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
   in \var{mode} è appropriato\footnote{per appropriato si intende che è
     impostato il permesso di scrittura per le operazioni di scrittura e quello
     di lettura per le operazioni di lettura.} l'accesso è consentito.
-\item se il group-ID effettivo del processo corrisponde o al
+\item se il \acr{gid} effettivo del processo corrisponde o al
   valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso
   per il gruppo in \var{mode} è appropriato l'accesso è consentito.
 \item se il permesso per gli altri è appropriato l'accesso è consentito.
@@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono:
   riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su
   funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo
   il medesimo errore. Questo comando può essere eseguito solo da un processo
-  con user-ID effettivo corrispondente al creatore o al proprietario della
+  con \acr{uid} effettivo corrispondente al creatore o al proprietario della
   coda, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in
@@ -1686,7 +1686,7 @@ 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
 il problema delle fifo che restavano nel filesystem). In questo caso però il
 problemi sono maggiori, sia perché è molto più facile esaurire la memoria
-dedicata ad una coda di messaggi che gli \index{inode} inode di un filesystem,
+dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem,
 sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client
 eseguito in un momento successivo potrebbe ricevere un messaggio non
 indirizzato a lui.
@@ -1957,14 +1957,14 @@ seguenti:
 \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture
   dati, con effetto immediato. Tutti i processi che erano stato di
   \textit{sleep} vengono svegliati, ritornando con un errore di
-  \errcode{EIDRM}.  L'user-ID effettivo del processo deve corrispondere o al
+  \errcode{EIDRM}.  L'\acr{uid} effettivo del processo deve corrispondere o al
   creatore o al proprietario dell'insieme, o all'amministratore. L'argomento
   \param{semnum} viene ignorato.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   dell'insieme. I valori devono essere passati in una struttura
   \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i
   campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno
-  significativi di \var{sem\_perm.mode}. L'user-ID effettivo del processo deve
+  significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve
   corrispondere o al creatore o al proprietario dell'insieme, o
   all'amministratore.  L'argomento \param{semnum} viene ignorato.
 \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo
@@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è:
     \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o
       \const{IPC\_RMID} senza i permessi necessari.
     \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il
-      valore del group-ID o dell'user-ID è troppo grande per essere
+      valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere
       memorizzato nella struttura puntata da \param{buf}.
     \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è
       valido.
@@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti:
 \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la
   rimozione, questo verrà cancellato effettivamente solo quando l'ultimo
   processo ad esso agganciato si sarà staccato. Questo comando può essere
-  eseguito solo da un processo con user-ID effettivo corrispondente o al
+  eseguito solo da un processo con \acr{uid} effettivo corrispondente o al
   creatore del segmento, o al proprietario del segmento, o all'amministratore.
 \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario
   del segmento.  Per modificare i valori di \var{shm\_perm.mode},
@@ -2608,7 +2608,7 @@ L'uso di \const{SHM\_RDONLY} permette di agganciare il segmento in sola
 lettura (si ricordi che anche le pagine di memoria hanno dei permessi), in tal
 caso un tentativo di scrivere sul segmento comporterà una
 \itindex{segment~violation} violazione di accesso con l'emissione di un
-segnale di \const{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
+segnale di \signal{SIGSEGV}. Il comportamento usuale di \func{shmat} è quello
 di agganciare il segmento con l'accesso in lettura e scrittura (ed il processo
 deve aver questi permessi in \var{shm\_perm}), non è prevista la possibilità
 di agganciare un segmento in sola scrittura.
@@ -2749,10 +2749,10 @@ ricavare la parte di informazione che interessa.
 
 In fig.~\ref{fig:ipc_dirmonitor_main} si è riportata la sezione principale del
 corpo del programma server, insieme alle definizioni delle altre funzioni
-usate nel programma e delle variabili globali, omettendo tutto quello che
-riguarda la gestione delle opzioni e la stampa delle istruzioni di uso a
-video; al solito il codice completo si trova con i sorgenti allegati nel file
-\file{DirMonitor.c}.
+usate nel programma e delle \index{variabili!globali} variabili globali,
+omettendo tutto quello che riguarda la gestione delle opzioni e la stampa
+delle istruzioni di uso a video; al solito il codice completo si trova con i
+sorgenti allegati nel file \file{DirMonitor.c}.
 
 \begin{figure}[!htbp]
   \footnotesize \centering
@@ -2764,11 +2764,11 @@ video; al solito il codice completo si trova con i sorgenti allegati nel file
   \label{fig:ipc_dirmonitor_main}
 \end{figure}
 
-Il programma usa delle variabili globali (\texttt{\small 2--14}) per mantenere
-i valori relativi agli oggetti usati per la comunicazione inter-processo; si è
-definita inoltre una apposita struttura \struct{DirProp} che contiene i dati
-relativi alle proprietà che si vogliono mantenere nella memoria condivisa, per
-l'accesso da parte dei client.
+Il programma usa delle \index{variabili!globali} variabili globali
+(\texttt{\small 2--14}) per mantenere i valori relativi agli oggetti usati per
+la comunicazione inter-processo; si è definita inoltre una apposita struttura
+\struct{DirProp} che contiene i dati relativi alle proprietà che si vogliono
+mantenere nella memoria condivisa, per l'accesso da parte dei client.
 
 Il programma, dopo la sezione, omessa, relativa alla gestione delle opzioni da
 riga di comando (che si limitano alla eventuale stampa di un messaggio di
@@ -2846,8 +2846,8 @@ Il codice di quest'ultima è riportato in fig.~\ref{fig:ipc_dirmonitor_sub}.
 Come si vede la funzione (\texttt{\small 2--16}) è molto semplice e si limita
 a chiamare (\texttt{\small 5}) la funzione \func{stat} sul file indicato da
 ciascuna voce, per ottenerne i dati, che poi utilizza per incrementare i vari
-contatori nella memoria condivisa, cui accede grazie alla variabile globale
-\var{shmptr}.
+contatori nella memoria condivisa, cui accede grazie alla
+\index{variabili!globali} variabile globale \var{shmptr}.
 
 Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
 principale del programma, con un mutex acquisito, perciò non è necessario
@@ -2958,7 +2958,7 @@ Totale  72 file, per 489887 byte
 %$
 
 A questo punto possiamo far uscire il server inviandogli un segnale di
-\const{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
+\signal{SIGTERM} con il comando \code{killall dirmonitor}, a questo punto
 ripetendo la lettura, otterremo un errore:
 \begin{Verbatim}
 [piccardi@gont sources]$ ./readmon 
@@ -3324,7 +3324,7 @@ quella particolare (si ricordi quanto visto in
 sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del
 SysV IPC.  Per quanto riguarda l'attribuzione dell'utente e del gruppo
 proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata
-secondo la semantica SysV: corrispondono cioè a user-ID e group-ID effettivi
+secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi
 del processo che esegue la creazione.
 
 
@@ -3868,7 +3868,7 @@ segmento di memoria condiviso con le stesse modalità di
 il flag \const{FD\_CLOEXEC}.  Chiamate effettuate da diversi processi usando
 lo stesso nome, restituiranno file descriptor associati allo stesso segmento
 (così come, nel caso di file di dati, essi sono associati allo stesso
-\index{inode} inode).  In questo modo è possibile effettuare una chiamata ad
+\itindex{inode} inode).  In questo modo è possibile effettuare una chiamata ad
 \func{mmap} sul file descriptor restituito da \func{shm\_open} ed i processi
 vedranno lo stesso segmento di memoria condivisa.
 
@@ -4055,8 +4055,8 @@ presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori
 usano la semantica standard dei file per quanto riguarda i controlli di
 accesso. 
 
-Questo significa che un nuovo semaforo viene sempre creato con l'user-ID ed il
-group-ID effettivo del processo chiamante, e che i permessi indicati con
+Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il
+\acr{gid} effettivo del processo chiamante, e che i permessi indicati con
 \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask}
 del processo.  Inoltre per poter aprire un semaforo è necessario avere su di
 esso sia il permesso di lettura che quello di scrittura.
@@ -4314,8 +4314,8 @@ Qualora il semaforo debba essere condiviso dai \itindex{thread}
 \textit{thread} di uno stesso processo (nel qual caso si parla di
 \textit{thread-shared semaphore}), occorrerà che \param{sem} sia l'indirizzo
 di una variabile visibile da tutti i \itindex{thread} \textit{thread}, si
-dovrà usare cioè una variabile globale o una variabile allocata dinamicamente
-nello \itindex{heap} \textit{heap}.
+dovrà usare cioè una \index{variabili!globali} variabile globale o una
+variabile allocata dinamicamente nello \itindex{heap} \textit{heap}.
 
 Qualora il semaforo debba essere condiviso fra più processi (nel qual caso si
 parla di \textit{process-shared semaphore}) la sola scelta possibile per
@@ -4397,9 +4397,9 @@ dall'altro programma prima di averla finita di stampare.
 
 La parte iniziale del programma contiene le definizioni (\texttt{\small 1--8})
 del gestore del segnale usato per liberare le risorse utilizzate, delle
-variabili globali contenenti i nomi di default del segmento di memoria
-condivisa e del semaforo (il default scelto è \texttt{messages}), e delle
-altre variabili utilizzate dal programma.
+\index{variabili!globali} variabili globali contenenti i nomi di default del
+segmento di memoria condivisa e del semaforo (il default scelto è
+\texttt{messages}), e delle altre variabili utilizzate dal programma.
 
 Come prima istruzione (\texttt{\small 10}) si è provveduto ad installare un
 gestore di segnale che consentirà di effettuare le operazioni di pulizia
@@ -4463,7 +4463,7 @@ ciclo.
 
 Per uscire in maniera corretta dal programma sarà necessario interromperlo con
 il break da tastiera (\texttt{C-c}), che corrisponde all'invio del segnale
-\const{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
+\signal{SIGINT}, per il quale si è installato (\texttt{\small 10}) una
 opportuna funzione di gestione, riportata in
 fig.~\ref{fig:ipc_posix_sem_shm_message_server_handler}. La funzione è molto
 semplice e richiama le funzioni di rimozione sia per il segmento di memoria