X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=09ff74b333fdba0fa749f6e27d1bd350a9ae9ef7;hp=0c6a4f218d7e376a0b205abb481384fd67eefafa;hb=5eaf11a5e3e4daaee677554b68f4ba3c92c67b84;hpb=39154797992fca1134da0f4456dfbe2f37d82269 diff --git a/ipc.tex b/ipc.tex index 0c6a4f2..09ff74b 100644 --- a/ipc.tex +++ b/ipc.tex @@ -561,7 +561,8 @@ Il secondo caso processo alla volta (nel qual caso basta usare due fifo, una per leggere ed una per scrivere), le cose diventano invece molto più complesse quando si vuole effettuare una comunicazione fra il server ed un numero imprecisato di -client; se il primo infatti può ricevere le richieste attraverso una fifo```\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per +client; se il primo infatti può ricevere le richieste attraverso una fifo +``\textsl{nota}'', per le risposte non si può fare altrettanto, dato che, per la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di leggerli, quando i dati inviati sono destinati a loro. @@ -1057,7 +1058,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 settati -rispettivamente al valore dell'userid e del groupid effettivo del processo che +rispettivamente al valore dell'user-ID e del group-ID 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. @@ -1077,12 +1078,12 @@ controlli \begin{itemize} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. -\item se l'userid effettivo del processo corrisponde o al valore del campo +\item se l'user-ID 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 è settato il permesso di scrittura per le operazioni di scrittura e quello di lettura per le operazioni di lettura.} l'accesso è consentito. -\item se il groupid effettivo del processo corrisponde o al +\item se il group-ID 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. @@ -1456,7 +1457,7 @@ eseguire; i valori possibili sono: riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su funzioni di di lettura o di scrittura sulla coda saranno svegliati ricevendo il medesimo errore. Questo comando può essere eseguito solo da un processo - con userid effettivo corrispondente al creatore o al proprietario della + con user-ID 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 @@ -2168,14 +2169,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'userid effettivo del processo deve corrispondere o al + \errcode{EIDRM}. L'user-ID 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'userid effettivo del processo deve + significativi di \var{sem\_perm.mode}. L'user-ID 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 @@ -2772,7 +2773,7 @@ attraverso l'argomento \param{cmd}, i valori possibili 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 userid effettivo corrispondente o al + eseguito solo da un processo con user-ID effettivo corrispondente o al creatore della coda, o al proprietario della coda, 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}, @@ -2940,18 +2941,18 @@ modalit Un esempio classico di uso della memoria condivisa è quello del ``\textit{monitor}'', in cui essa viene per scambiare informazioni fra un -processo ``server'' che vi scrive dei dati di interesse generale che ha -ottenuto, e tutti i processi ``client'' interessati agli stessi dati che così +processo server che vi scrive dei dati di interesse generale che ha +ottenuto, e tutti i processi client interessati agli stessi dati che così possono leggerli in maniera completamente asincrona. Con questo schema di -funzionamento da una parte si evita che ciascun processo ``client'' debba +funzionamento da una parte si evita che ciascun processo client debba compiere l'operazione, potenzialmente onerosa, di ricavare e trattare i dati, -e dall'altra si evita al processo ``server'' di dover gestire l'invio a tutti +e dall'altra si evita al processo server di dover gestire l'invio a tutti i client di tutti i dati (non potendo il server sapere quali di essi servono effettivamente al singolo client). -Nel nostro caso implementeremo un ``monitor'' di una directory: un processo si -incaricherà di tenere sotto controllo alcuni parametri relativi ad una -directory (il numero dei file contenuti, la dimensione totale, ecc.) che +Nel nostro caso implementeremo un ``\textsl{monitor}'' di una directory: un +processo si incaricherà di tenere sotto controllo alcuni parametri relativi ad +una directory (il numero dei file contenuti, la dimensione totale, ecc.) che saranno salvati in un segmento di memoria condivisa cui altri processi potranno accedere per ricavare la parte di informazione che interessa. @@ -3025,12 +3026,13 @@ caratteristica della funzione \func{open} (illustrata in \secref{sec:file_open}) che prevede\footnote{questo è quanto dettato dallo standard POSIX.1, ciò non toglie che in alcune implementazioni questa tecnica possa non funzionare; in particolare per Linux, nel caso di NFS, si - è comunque soggetti alla possibilità di una race condition.} che essa -ritorni un errore quando usata con i flag di \const{O\_CREAT} e -\const{O\_EXCL}. In tal modo la creazione di un \textsl{file di lock} può -essere eseguita atomicamente, il processo che crea il file con successo si può -considerare come titolare del lock (e della risorsa ad esso associata) mentre -il rilascio si può eseguire con una chiamata ad \func{unlink}. + è comunque soggetti alla possibilità di una race + condition\index{race condition}.} che essa ritorni un errore quando usata +con i flag di \const{O\_CREAT} e \const{O\_EXCL}. In tal modo la creazione di +un \textsl{file di lock} può essere eseguita atomicamente, il processo che +crea il file con successo si può considerare come titolare del lock (e della +risorsa ad esso associata) mentre il rilascio si può eseguire con una chiamata +ad \func{unlink}. Un esempio dell'uso di questa funzione è mostrato dalle funzioni \func{LockFile} ed \func{UnlockFile} riportate in \figref{fig:ipc_file_lock}