X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=ipc.tex;h=bd5b25d985d6711aaf0ce043ffb5587ab0c6c312;hb=b26cbb461558b73852b680d524e8f91675998116;hp=e76fd7b06e7a4c25dd0dec87ce97535845ad18fd;hpb=041fde8aba0e18bb746653a060619b32ea9240ce;p=gapil.git diff --git a/ipc.tex b/ipc.tex index e76fd7b..bd5b25d 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 @@ -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 @@ -1916,7 +1917,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 +1941,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: @@ -2768,11 +2769,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 +3313,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