X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=fca22f02a1581a663fec2d7b75112657e9824a79;hp=c7f2c4ac14cb41424d78040deb1eaf58f116d89b;hb=fd86592a845b5f76ad43ba2374ca0b798ffca595;hpb=da0899b61653d07d75c8df134906261f1afd2485 diff --git a/ipc.tex b/ipc.tex index c7f2c4a..fca22f0 100644 --- a/ipc.tex +++ b/ipc.tex @@ -561,9 +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 -``nota'', per le risposte non si può fare altrettanto, dato che, per la -struttura sequenziale delle fifo, i client dovrebbero sapere, prima 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 +la struttura sequenziale delle fifo, i client dovrebbero sapere, prima di leggerli, quando i dati inviati sono destinati a loro. Per risolvere questo problema, si può usare un'architettura come quella @@ -1058,7 +1057,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. @@ -1078,12 +1077,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. @@ -1457,7 +1456,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 @@ -1922,7 +1921,7 @@ della risorsa; in generale per utilizzando il valore del contatore come indicatore del ``numero di risorse'' ancora disponibili. -Il sistema di comunicazione interprocesso di \textit{SysV IPC} prevede anche i +Il sistema di comunicazione inter-processo di \textit{SysV IPC} prevede anche i semafori, ma gli oggetti utilizzati non sono semafori singoli, ma gruppi di semafori detti \textsl{insiemi} (o \textit{semaphore set}); la funzione che permette di creare o ottenere l'identificatore di un insieme di semafori è @@ -2169,14 +2168,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 @@ -2773,7 +2772,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}, @@ -2939,20 +2938,20 @@ sequenziale\footnote{come accennato in \secref{sec:ipc_sysv_mq} per la effettuata in forma di messaggio.} o quando non può avvenire secondo una modalità predefinita. -Un esempio classico di uso della memoria condivisa è quello del ``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ì possono leggerli in maniera -completamente asincrona. Con questo schema di funzionamento da una parte si -evita che ciascun processo ``client'' debbia 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 i client di tutti i -dati (non potendo il server sapere quali di essi servono effettivamente al -singolo client). +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ì +possono leggerli in maniera completamente asincrona. Con questo schema di +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 +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 dimenzione totale, ecc.) che +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.