\secref{sec:sig_sigaction}).
Per far questo però occorre utilizzare le funzionalità dei segnali real-time
-(vedi \secref{sec:sig_real_time}) imopstando esplicitamente con il comando
+(vedi \secref{sec:sig_real_time}) impostando esplicitamente con il comando
\macro{F\_SETSIG} di \func{fcntl} un segnale real-time da inviare in caso di
I/O asincrono (il segnale predefinito è \macro{SIGIO}). In questo caso il
manipolatore tutte le volte che riceverà \macro{SI\_SIGIO} come valore del
\param{count}. Ciascuna struttura dovrà essere inizializzata per
opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il
trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li
-si sono specificati nel vattore \var{vector}.
+si sono specificati nel vettore \var{vector}.
\subsection{File mappati in memoria}
\centering
\includegraphics[width=9.5cm]{img/mmap_layout}
\caption{Disposizione della memoria di un processo quando si esegue la
- mappatuara in memoria di un file.}
+ mappatura in memoria di un file.}
\label{fig:file_mmap_layout}
\end{figure}
argomenti \param{fd} e \param{offset} sono
ignorati.\footnotemark\\
\macro{MAP\_ANON} & Sinonimo di \macro{MAP\_ANONYMOUS}, deprecato.\\
- \macro{MAP\_FILE} & Valore di compatibiità, deprecato.\\
+ \macro{MAP\_FILE} & Valore di compatibilità, deprecato.\\
\hline
\end{tabular}
\caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
\centering
\includegraphics[width=10cm]{img/mmap_boundary}
\caption{Schema della mappatura in memoria di una sezione di file di
- dimensioni non corripondenti al bordo di una pagina.}
+ dimensioni non corrispondenti al bordo di una pagina.}
\label{fig:file_mmap_boundary}
\end{figure}
associato alla presenza del permesso di esecuzione. Impostando questo bit su
un file senza permesso di esecuzione in un sistema che supporta il
\textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il file
-in questione. In questo modo una combinaizone dei permessi originariamente non
+in questione. In questo modo una combinazione dei permessi originariamente non
contemplata, in quanto senza significato, diventa l'indicazione della presenza
o meno del \textit{mandatory locking}.
</font>
</b>
</td>
- <td bgcolor="lightblue">
+ <td bgcolor="lightblue"> <b>GaPiL</b> è in continua evoluzione ma
+ alcune parti hanno raggiunto una "stabilità" sufficiente (nel
+ senso che le ho riviste, le ritengo abbastanza complete, e non
+ sono stato capace di accorgermi degli errori che ci ho lasciato)
+ altre sono da rivedere, altre sono solo parzialmente accennate. La
+ situazione attuale è la seguente:
+ <table width="600" cellspacing="5">
+ <tbody>
+ <tr>
+ <td valign="top"> <b> Cap. 1 </b> </td>
+ <td valign="top"> Introduzione </td>
+ <td valign="top"> completo e revisionato</td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 2-3 </b> </td>
+ <td valign="top"> Gestione dei processi </td>
+ <td valign="top"> completi e revisionati</td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 4-7 </b> </td>
+ <td valign="top"> Gestione base dei file
+ <td valign="top"> completi, parzialmente revisionati</td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 8 </b> </td>
+ <td valign="top"> Sistema, parametri, errori</td>
+ <td valign="top"> completo, da revisionare</td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 9 </b> </td>
+ <td valign="top"> Segnali</td>
+ <td valign="top"> completo, da revisionare </td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 10 </b> </td>
+ <td valign="top"> Sessioni e terminali</td>
+ <td valign="top"> Sessioni abbozzate, terminali da fare </td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 11 </b> </td>
+ <td valign="top"> Gestione avanzata dei file</td>
+ <td valign="top"> I/O avanzato abbozzato, file locking
+ accennato </td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 12 </b> </td>
+ <td valign="top"> IPC</td>
+ <td valign="top"> Pipe e fifo complete, abbozzate code e
+ semafori, POSIX IPC da fare </td>
+ <tr>
+ <td valign="top"> <b> Cap. 13-14 </b> </td>
+ <td valign="top"> Introduzione alla rete</td>
+ <td valign="top"> completi, da revisionare </td>
+ </tr>
+ <tr>
+ <td valign="top"> <b> Cap. 15-16 </b> </td>
+ <td valign="top"> Socket TCP elementari</td>
+ <td valign="top"> Caratteristiche base complete, esempio
+ elementare da concludere </td>
+ </tr>
+ </tbody>
+ </table>
<p>
- <b>24 - settembre - 2002</b> <br> Sedici capitoli, 373 pagine.
+ <b> Versione corrente:</b> 373 pagine.
</p>
</td>
</tr>
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}.
sessione ad un processo è quello di crearne una nuova con l'uso di
\func{setsid}; il suo prototipo è:
\begin{prototype}{unistd.h}{pid\_t setsid(void)}
- Crea una nuova sessione sul processo corrente settandone \acr{sid} e
+ Crea una nuova sessione sul processo corrente impostandone \acr{sid} e
\acr{pgid}.
\bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di
errore, il solo errore possibile è \macro{EPERM}, che si ha quando il
- \acr{pgid} e \acr{pid} del processo concidono.}
+ \acr{pgid} e \acr{pid} del processo coincidono.}
\end{prototype}
La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al
In genere (a meno di redirezioni) nelle sessioni di lavoro questo terminale è
associato ai file standard (di input, output ed error) dei processi nella
-sessione, ma solo quelli che fanno parte del cosiddetto ragruppamento di
+sessione, ma solo quelli che fanno parte del cosiddetto raggruppamento di
\textit{foreground}, possono leggere e scrivere in certo istante. Per
impostare il raggruppamento di \textit{foreground} di un terminale si usa la
funzione \func{tcsetpgrp}, il cui prototipo è:
\func{waitpid}.} Se però si bloccano o ignorano i due segnali citati, le
funzioni di lettura e scrittura falliranno con un errore di \macro{EIO}.
-Un processo può contollare qual'è il gruppo di \textit{foreground} associato
+Un processo può controllare qual'è il gruppo di \textit{foreground} associato
ad un terminale con la funzione \func{tcgetpgrp}, il cui prototipo è:
\begin{functions}
\headdecl{unistd.h} \headdecl{termios.h}
aver rediretto l'output di accedere al terminale di controllo, pur non
disponendo più del file descriptor originario; un caso tipico è il programma
\cmd{crypt} che accetta la redirezione sullo standard input di un file da
-decrittare, ma deve poi leggere la password dal terminale.
+decifrare, ma deve poi leggere la password dal terminale.
Un'altra caratteristica del terminale di controllo usata nel job control è che
utilizzando su di esso le combinazioni di tasti speciali (\cmd{C-z},
connessione di rete. Dato che i concetti base sono gli stessi, e dato che alla
fine le differenze sono\footnote{in generale nel caso di login via rete o di
terminali lanciati dall'interfaccia grafica cambia anche il processo da cui
- ha origine l'esecuzione della shell.} nel device cui il kernel associa i
+ ha origine l'esecuzione della shell.} nel dispositivo cui il kernel associa i
file standard (vedi \secref{sec:file_std_descr}) per l'I/O, tratteremo solo il
caso classico del terminale.
telescriventi (\textit{teletype}), da cui deriva sia il nome dell'interfaccia,
\textit{tty}, che quello dei relativi file di dispositivo, che sono sempre
della forma \texttt{/dev/tty*}.\footnote{questo vale anche per i terminali
- vitruali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
+ virtuali associati alle connessioni di rete con \cmd{telnet} o \cmd{ssh}.}
Per controllare un terminale si usa di solito il programma \cmd{getty} (od una
delle sue varianti), che permette di mettersi in ascolto su uno di questi
\func{setsid} per creare una nuova sessione ed un nuovo process group, e di
aprire il terminale (che così diventa il terminale di controllo della
sessione) in lettura sullo standard input ed in scrittura sullo standard
-output e sullo standard error; inoltre effettuarà, qualora servano, ulteriori
+output e sullo standard error; inoltre effettuerà, qualora servano, ulteriori
settaggi.\footnote{ad esempio, come qualcuno si sarà accorto scrivendo un nome
di login in maiuscolo, può effettuare la conversione automatica dell'input
in minuscolo, ponendosi in una modalità speciale che non distingue fra i due
projects / gapil.git / commitdiff