Abbiamo già visto in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
\func{mkfifo} che permettono di creare una fifo; per utilizzarne una un
-processo non avrà che da aprire il relativo file speciale o in lettura o
-scrittura; nel primo caso sarà collegato al capo di uscita della fifo, e dovrà
-leggere, nel secondo al capo di ingresso, e dovrà scrivere.
+processo non avrà che da aprire il relativo \index{file!speciali} file
+speciale o in lettura o scrittura; nel primo caso sarà collegato al capo di
+uscita della fifo, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
+scrivere.
Il kernel crea una singola pipe per ciascuna fifo che sia stata aperta, che può
essere acceduta contemporaneamente da più processi, sia in lettura che in
oggetti di comunicazione che, come le pipe, sono utilizzati attraverso dei
file descriptor.} nell'ambito dell'interfaccia generale che essi forniscono
per la programmazione di rete; e vedremo anche
-(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei file speciali
-(di tipo socket, analoghi a quello associati alle fifo) cui si accede però
-attraverso quella medesima interfaccia; vale però la pena esaminare qui una
-modalità di uso dei socket locali\footnote{la funzione \func{socketpair} è
- stata introdotta in BSD4.4, ma è supportata in genere da qualunque sistema
- che fornisca l'interfaccia dei socket.} che li rende sostanzialmente
-identici ad una pipe bidirezionale.
+(in~sez.~\ref{sec:sock_sa_local}) come si possono definire dei
+\index{file!speciali} file speciali (di tipo socket, analoghi a quello
+associati alle fifo) cui si accede però attraverso quella medesima
+interfaccia; vale però la pena esaminare qui una modalità di uso dei socket
+locali\footnote{la funzione \func{socketpair} è stata introdotta in BSD4.4, ma
+ è supportata in genere da qualunque sistema che fornisca l'interfaccia dei
+ socket.} che li rende sostanzialmente identici ad una pipe bidirezionale.
La funzione \funcd{socketpair} infatti consente di creare una coppia di file
descriptor connessi fra di loro (tramite un socket, appunto), senza dover
-ricorrere ad un file speciale sul filesystem, i descrittori sono del tutto
-analoghi a quelli che si avrebbero con una chiamata a \func{pipe}, con la sola
-differenza è che in questo caso il flusso dei dati può essere effettuato in
-entrambe le direzioni. Il prototipo della funzione è:
+ricorrere ad un \index{file!speciali} file speciale sul filesystem, i
+descrittori sono del tutto analoghi a quelli che si avrebbero con una chiamata
+a \func{pipe}, con la sola differenza è che in questo caso il flusso dei dati
+può essere effettuato in entrambe le direzioni. Il prototipo della funzione è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/socket.h}
leggendo), poi (\texttt{\small 44}) si cancellano i valori precedentemente
immagazzinati nella memoria condivisa con \func{memset}, e si esegue
(\texttt{\small 45}) un nuovo calcolo degli stessi utilizzando la funzione
-\func{DirScan}; infine (\texttt{\small 46}) si sblocca il mutex con
+\myfunc{dir\_scan}; infine (\texttt{\small 46}) si sblocca il mutex con
\func{MutexUnlock}, e si attende (\texttt{\small 47}) per il periodo di tempo
specificato a riga di comando con l'opzione \code{-p} con una \func{sleep}.
Si noti come per il calcolo dei valori da mantenere nella memoria condivisa si
-sia usata ancora una volta la funzione \func{DirScan}, già utilizzata (e
+sia usata ancora una volta la funzione \myfunc{dir\_scan}, già utilizzata (e
descritta in dettaglio) in sez.~\ref{sec:file_dir_read}, che ci permette di
effettuare la scansione delle voci della directory, chiamando per ciascuna di
esse la funzione \func{ComputeValues}, che esegue tutti i calcoli necessari.
contatori nella memoria condivisa, cui accede grazie alla
\index{variabili!globali} variabile globale \var{shmptr}.
-Dato che la funzione è chiamata da \func{DirScan}, si è all'interno del ciclo
-principale del programma, con un mutex acquisito, perciò non è necessario
-effettuare nessun controllo e si può accedere direttamente alla memoria
-condivisa usando \var{shmptr} per riempire i campi della struttura
+Dato che la funzione è chiamata da \myfunc{dir\_scan}, si è all'interno del
+ciclo principale del programma, con un mutex acquisito, perciò non è
+necessario effettuare nessun controllo e si può accedere direttamente alla
+memoria condivisa usando \var{shmptr} per riempire i campi della struttura
\struct{DirProp}; così prima (\texttt{\small 6--7}) si sommano le dimensioni
dei file ed il loro numero, poi, utilizzando le macro di
tab.~\ref{tab:file_type_macro}, si contano (\texttt{\small 8--14}) quanti ce
sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
\itindend{memory~mapping}
-% TODO fare esempio di mmap anonima
+% TODO: fare esempio di mmap anonima
+
+% TODO: con il kernel 3.2 è stata introdotta un nuovo meccanismo di
+% intercomunicazione veloce chiamato Cross Memory Attach, da capire se e come
+% trattarlo qui, vedi http://lwn.net/Articles/405346/
+% https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcf634098c00dd9cd247447368495f0b79be12d1
\section{L'intercomunicazione fra processi di POSIX}
\label{sec:ipc_posix}
% LocalWords: dtime lpid cpid nattac shmall shmmax SHMLBA SHMSEG EOVERFLOW brk
% LocalWords: memory shmat shmdt void shmaddr shmflg SVID RND RDONLY rounded
% LocalWords: SIGSEGV nattch exit SharedMem ShmCreate memset fill ShmFind home
-% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr DirScan ipcs NFS
+% LocalWords: ShmRemove DirMonitor DirProp chdir GaPiL shmptr ipcs NFS
% LocalWords: ComputeValues ReadMonitor touch SIGTERM dirmonitor unlink fcntl
% LocalWords: LockFile UnlockFile CreateMutex FindMutex LockMutex SETLKW GETLK
% LocalWords: UnlockMutex RemoveMutex ReadMutex UNLCK WRLCK RDLCK mapping MAP