X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=e6b45de65be21c0d310fca5609d8e467311a5626;hp=e76fd7b06e7a4c25dd0dec87ce97535845ad18fd;hb=9a6d19e384fe9b1afbe4d9124ac34eaf7aa57562;hpb=041fde8aba0e18bb746653a060619b32ea9240ce diff --git a/ipc.tex b/ipc.tex index e76fd7b..e6b45de 100644 --- a/ipc.tex +++ b/ipc.tex @@ -98,7 +98,7 @@ capo della pipe, l'altro pu Tutto ciò ci mostra come sia immediato realizzare un meccanismo di comunicazione fra processi attraverso una pipe, utilizzando le proprietà -ordinarie dei file, ma ci mostra anche qual'è il principale\footnote{Stevens +ordinarie dei file, ma ci mostra anche qual è il principale\footnote{Stevens in \cite{APUE} riporta come limite anche il fatto che la comunicazione è unidirezionale, ma in realtà questo è un limite facilmente superabile usando una coppia di pipe.} limite nell'uso delle pipe. È necessario infatti che i @@ -135,14 +135,14 @@ di un'altro. Realizzeremo il programma di esempio nella forma di un \textit{CGI}\footnote{Un CGI (\textit{Common Gateway Interface}) è un programma che permette la creazione dinamica di un oggetto da inserire all'interno di una pagina HTML.} per Apache, che genera una immagine JPEG -di un codice a barre, specificato come parametro di input. +di un codice a barre, specificato come argomento in ingresso. Un programma che deve essere eseguito come \textit{CGI} deve rispondere a delle caratteristiche specifiche, esso infatti non viene lanciato da una shell, ma dallo stesso web server, alla richiesta di una specifica URL, che di solito ha la forma: \begin{verbatim} - http://www.sito.it/cgi-bin/programma?parametro + http://www.sito.it/cgi-bin/programma?argomento \end{verbatim} ed il risultato dell'elaborazione deve essere presentato (con una intestazione che ne descrive il mime-type) sullo standard output, in modo che il web-server @@ -371,7 +371,7 @@ dei programmi effettivamente eseguiti. Questo non comporta nessun problema dato che la lettura su una pipe è bloccante, per cui ciascun processo, per quanto lanciato per primo, si bloccherà in attesa di ricevere sullo standard input il -risultato dell'elaborazione del precedente, benchè quest'ultimo venga invocato +risultato dell'elaborazione del precedente, benché quest'ultimo venga invocato dopo. \begin{figure}[!htb] @@ -761,11 +761,12 @@ effettuato in entrambe le direzioni. Il prototipo della funzione La funzione restituisce in \param{sv} la coppia di descrittori connessi fra di loro: quello che si scrive su uno di essi sarà ripresentato in input -sull'altro e viceversa. I parametri \param{domain}, \param{type} e -\param{protocol} derivano dall'interfaccia dei socket\index{socket} (che è -quella che fornisce il substrato per connettere i due descrittori), ma in -questo caso i soli valori validi che possono essere specificati sono -rispettivamente \const{AF\_UNIX}, \const{SOCK\_STREAM} e \val{0}. +sull'altro e viceversa. Gli argomenti \param{domain}, \param{type} e +\param{protocol} derivano dall'interfaccia dei socket\index{socket} (vedi +sez.~\ref{sec:sock_creation}) che è quella che fornisce il substrato per +connettere i due descrittori, ma in questo caso i soli valori validi che +possono essere specificati sono rispettivamente \const{AF\_UNIX}, +\const{SOCK\_STREAM} e \val{0}. L'utilità di chiamare questa funzione per evitare due chiamate a \func{pipe} può sembrare limitata; in realtà l'utilizzo di questa funzione (e dei @@ -848,14 +849,14 @@ mantiene varie propriet Usando la stessa chiave due processi diversi possono ricavare l'identificatore associato ad un oggetto ed accedervi. Il problema che sorge a questo punto è come devono fare per accordarsi sull'uso di una stessa chiave. Se i processi -sono \textsl{parenti} la soluzione è relativamente semplice, in tal caso +sono \textsl{imparentati} la soluzione è relativamente semplice, in tal caso infatti si può usare il valore speciale \texttt{IPC\_PRIVATE} per creare un nuovo oggetto nel processo padre, l'identificatore così ottenuto sarà -disponibile in tutti i figli, e potrà essere passato come parametro attraverso +disponibile in tutti i figli, e potrà essere passato come argomento attraverso una \func{exec}. -Però quando i processi non sono \textsl{parenti} (come capita tutte le volte -che si ha a che fare con un sistema client-server) tutto questo non è +Però quando i processi non sono \textsl{imparentati} (come capita tutte le +volte che si ha a che fare con un sistema client-server) tutto questo non è possibile; si potrebbe comunque salvare l'identificatore su un file noto, ma questo ovviamente comporta lo svantaggio di doverselo andare a rileggere. Una alternativa più efficace è quella che i programmi usino un valore comune per @@ -1185,22 +1186,23 @@ file \file{msgmax}, \file{msgmnb} e \file{msgmni} di \file{/proc/sys/kernel/}. \end{figure} -Una coda di messaggi è costituita da una \textit{linked list};\footnote{una - \textit{linked list} è una tipica struttura di dati, organizzati in una - lista in cui ciascun elemento contiene un puntatore al successivo. In questo - modo la struttura è veloce nell'estrazione ed immissione dei dati dalle - estremità dalla lista (basta aggiungere un elemento in testa o in coda ed - aggiornare un puntatore), e relativamente veloce da attraversare in ordine - sequenziale (seguendo i puntatori), è invece relativamente lenta - nell'accesso casuale e nella ricerca.} i nuovi messaggi vengono inseriti in -coda alla lista e vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si -è riportato lo schema con cui queste strutture vengono mantenute dal -kernel.\footnote{lo schema illustrato in fig.~\ref{fig:ipc_mq_schema} è in - realtà una semplificazione di quello usato effettivamente fino ai kernel - della serie 2.2.x, nei kernel della serie 2.4.x la gestione delle code di - messaggi è stata modificata ed è effettuata in maniera diversa; abbiamo - mantenuto lo schema precedente in quanto illustra comunque in maniera più - che adeguata i principi di funzionamento delle code di messaggi.} +Una coda di messaggi è costituita da una +\index{\textit{linked~list}}\textit{linked list};\footnote{una \textit{linked + list} è una tipica struttura di dati, organizzati in una lista in cui + ciascun elemento contiene un puntatore al successivo. In questo modo la + struttura è veloce nell'estrazione ed immissione dei dati dalle estremità + dalla lista (basta aggiungere un elemento in testa o in coda ed aggiornare + un puntatore), e relativamente veloce da attraversare in ordine sequenziale + (seguendo i puntatori), è invece relativamente lenta nell'accesso casuale e + nella ricerca.} i nuovi messaggi vengono inseriti in coda alla lista e +vengono letti dalla cima, in fig.~\ref{fig:ipc_mq_schema} si è riportato lo +schema con cui queste strutture vengono mantenute dal kernel.\footnote{lo + schema illustrato in fig.~\ref{fig:ipc_mq_schema} è in realtà una + semplificazione di quello usato effettivamente fino ai kernel della serie + 2.2.x, nei kernel della serie 2.4.x la gestione delle code di messaggi è + stata modificata ed è effettuata in maniera diversa; abbiamo mantenuto lo + schema precedente in quanto illustra comunque in maniera più che adeguata i + principi di funzionamento delle code di messaggi.} \begin{figure}[!htb] \footnotesize \centering @@ -1916,7 +1918,7 @@ loro inizializzazione) } \end{functions} -La funzione può avere tre o quattro parametri, a seconda dell'operazione +La funzione può avere tre o quattro argomenti, a seconda dell'operazione specificata con \param{cmd}, ed opera o sull'intero insieme specificato da \param{semid} o sul singolo semaforo di un insieme, specificato da \param{semnum}. @@ -1940,7 +1942,7 @@ definizione, con i possibili valori che pu fig.~\ref{fig:ipc_semun}. Come già accennato sia il comportamento della funzione che il numero di -parametri con cui deve essere invocata, dipendono dal valore dell'argomento +argomenti con cui deve essere invocata dipendono dal valore dell'argomento \param{cmd}, che specifica l'azione da intraprendere; i valori validi (che cioè non causano un errore di \errcode{EINVAL}) per questo argomento sono i seguenti: @@ -2556,9 +2558,9 @@ direttamente, la situazione dopo l'esecuzione di \func{shmat} fig.~\ref{fig:ipc_shmem_layout} (per la comprensione del resto dello schema si ricordi quanto illustrato al proposito in sez.~\ref{sec:proc_mem_layout}). In particolare l'indirizzo finale del segmento dati (quello impostato da -\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk}) non viene influenzato. Si tenga -presente infine che la funzione ha successo anche se il segmento è stato -marcato per la cancellazione. +\func{brk}, vedi sez.~\ref{sec:proc_mem_sbrk_alloca}) non viene influenzato. +Si tenga presente infine che la funzione ha successo anche se il segmento è +stato marcato per la cancellazione. \begin{figure}[htb] \centering @@ -2639,7 +2641,7 @@ dell'interfaccia, \funcd{shmdt}, il cui prototipo \bodydesc{La funzione restituisce 0 in caso di successo, e -1 in caso di errore, la funzione fallisce solo quando non c'è un segmento agganciato - all'indirizzo \func{shmaddr}, con \var{errno} che assume il valore + all'indirizzo \param{shmaddr}, con \var{errno} che assume il valore \errval{EINVAL}.} \end{functions} @@ -2768,11 +2770,11 @@ 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 aiuto a video ed all'impostazione della durata dell'intervallo con cui viene ripetuto il calcolo delle proprietà della directory) controlla (\texttt{\small - 20--23}) che sia stato specificato il parametro necessario contenente il -nome della directory da tenere sotto controllo, senza il quale esce -immediatamente con un messaggio di errore. + 20--23}) che sia stato specificato l'argoemnto necessario contenente il nome +della directory da tenere sotto controllo, senza il quale esce immediatamente +con un messaggio di errore. -Poi, per verificare che il parametro specifichi effettivamente una directory, +Poi, per verificare che l'argomento specifichi effettivamente una directory, si esegue (\texttt{\small 24--26}) su di esso una \func{chdir}, uscendo immediatamente in caso di errore. Questa funzione serve anche per impostare la directory di lavoro del programma nella directory da tenere sotto @@ -3312,9 +3314,9 @@ processo che esegue la creazione). Le code di messaggi non sono ancora supportate nel kernel ufficiale, esiste però una implementazione sperimentale di Michal Wronski e Krzysztof Benedyczak,\footnote{i patch al kernel e la relativa libreria possono essere - trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc} - {http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}, questi sono stati - inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In +trovati su \href{http://www.mat.uni.torun.pl/~wrona/posix_ipc} +{\textsf{http://www.mat.uni.torun.pl/\tild{}wrona/posix\_ipc}}, questi sono +stati inseriti nel kernel ufficiale a partire dalla versione 2.6.6-rc1.}. In generale, come le corrispettive del SysV IPC, le code di messaggi sono poco usate, dato che i socket\index{socket}, nei casi in cui sono sufficienti, sono più comodi, e che in casi più complessi la comunicazione può essere gestita