Nel nostro caso la prima apertura si bloccherà fintanto che un qualunque
client non apre a sua volta la fifo nota in scrittura per effettuare la sua
-richiesta. Pertanto all'inizio non ci sono probelmi, il client però, una volta
+richiesta. Pertanto all'inizio non ci sono problemi, il client però, una volta
ricevuta la risposta, uscirà, chiudendo tutti i file aperti, compresa la fifo.
A questo punto il server resta (se non ci sono altri client che stanno
effettuando richieste) con la fifo chiusa sul lato in lettura e a questo punto
Inoltrata la richiesta si può passare alla lettura della risposta; anzitutto
si apre (\texttt{\small 26--30}) la fifo appena creata, da cui si deve
-riceverla, dopodiché si effettua una lettura (\texttt{\small 31})
+riceverla, dopo di che si effettua una lettura (\texttt{\small 31})
nell'apposito buffer; si è supposto, come è ragionevole, che le frasi inviate
dal server siano sempre di dimensioni inferiori a \macro{PIPE\_BUF},
tralasciamo la gestione del caso in cui questo non è vero. Infine si stampa
\file{/dev/hda1} e \file{/dev/sda1}.
In genere quello che si fa è utilizzare un file comune usato dai programmi che
-devono comunicare (ad esempio un haeder comune, o uno dei programmi che devono
+devono comunicare (ad esempio un header comune, o uno dei programmi che devono
usare l'oggetto in questione), utilizzando il numero di progetto per ottenere
le chiavi che interessano. In ogni caso occorre sempre controllare, prima di
creare un oggetto, che la chiave non sia già stata utilizzata. Se questo va
al kernel 2.2.x questi valori, definiti dalle costanti \macro{MSGMNI},
\macro{SEMMNI} e \macro{SHMMNI}, potevano essere cambiati (come tutti gli
altri limiti relativi al \textit{System V IPC}) solo con una ricompilazione
- del kernel, andando a modificarne la definizione nei relativi haeder file.
+ del kernel, andando a modificarne la definizione nei relativi header file.
A partire dal kernel 2.4.x è possibile cambiare questi valori a sistema
attivo scrivendo sui file \file{shmmni}, \file{msgmni} e \file{sem} di
\file{/proc/sys/kernel} o con l'uso di \texttt{syscntl}.} e per ciascuno di
Il primo grave difetto è che non esiste una funzione che permetta di creare ed
inizializzare un semaforo in un'unica chiamata; occorre prima creare l'insieme
dei semafori con \func{semget} e poi inizializzarlo con \func{semctl}, si
-perde così ogni possibilità di esegure atomicamente questa operazione.
+perde così ogni possibilità di eseguire atomicamente questa operazione.
Il secondo difetto deriva dalla caratteristica generale degli oggetti del
System V IPC di essere risorse globali di sistema, che non vengono cancellate
effettuata, viene inizializzato a zero.
\end{itemize*}
-Ciascun semaforo dell'isnsieme è realizzato come una struttura di tipo
+Ciascun semaforo dell'insieme è realizzato come una struttura di tipo
\var{sem} che ne contiene i dati essenziali, la sua definizione\footnote{si è
riportata la definizione originaria del kernel 1.0, che contiene la prima
realizzazione del System V IPC in Linux. In realtà questa struttura ormai è
\end{lstlisting}
\end{minipage}
\normalsize
- \caption{La struttura \var{sem}, che contiene i dati di un signolo semaforo.}
+ \caption{La struttura \var{sem}, che contiene i dati di un singolo semaforo.}
\label{fig:ipc_sem}
\end{figure}
La funzione può avere tre o quattro parametri, a seconda dell'operazione
specificata con \param{cmd}, ed opera o sull'intero insieme specificato da
-\param{semid} o sul sigolo semaforo di un insieme, specificato da
+\param{semid} o sul singolo semaforo di un insieme, specificato da
\param{semnum}. Qualora la funzione operi con quattro argomenti \param{arg} è
un argomento generico che deve essere una \var{union semun}, si è riportato la
relativa definizione in \figref{fig:ipc_semun}.
projects / gapil.git / blobdiff