X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=ipc.tex;h=35095a445dd71e487e2f049d3fa23b9fa40f9f0c;hp=9b10da1853be5343586a8da09cb3dd3262367c76;hb=88d22f4971adcbdb816c405a1375ae0a8d57bdde;hpb=2ee09e1100e6d070dbf5d4d13d900dba516d83de

diff --git a/ipc.tex b/ipc.tex
index 9b10da1..35095a4 100644
--- a/ipc.tex
+++ b/ipc.tex
@@ -1,6 +1,6 @@
 %% ipc.tex
 %%
-%% Copyright (C) 2000-2014 Simone Piccardi.  Permission is granted to
+%% Copyright (C) 2000-2015 Simone Piccardi.  Permission is granted to
 %% copy, distribute and/or modify this document under the terms of the GNU Free
 %% Documentation License, Version 1.1 or any later version published by the
 %% Free Software Foundation; with the Invariant Sections being "Un preambolo",
@@ -122,7 +122,7 @@ fra \const{O\_NONBLOCK} o \const{O\_CLOEXEC} che hanno l'effetto di impostare
 su entrambi i file descriptor restituiti dalla funzione i relativi flag, già
 descritti per \func{open} in tab.~\ref{tab:open_operation_flag}, che attivano
 rispettivamente la modalità di accesso \textsl{non-bloccante} ed il
-\textit{close-on-exec} \itindex{close-on-exec}.
+\textit{close-on-exec}.
 
 Chiaramente creare una \textit{pipe} all'interno di un singolo processo non
 serve a niente; se però ricordiamo quanto esposto in
@@ -369,8 +369,8 @@ La funzione restituisce il puntatore ad uno stream associato alla
   input}) in caso di \code{w}. A partire dalla versione 2.9 delle \acr{glibc}
 (questa è una estensione specifica di Linux) all'argomento \param{type} può
 essere aggiunta la lettera ``\texttt{e}'' per impostare automaticamente il
-flag di \textit{close-on-exec} \itindex{close-on-exec} sul file descriptor
-sottostante (si ricordi quanto spiegato in sez.~\ref{sec:file_open_close}).
+flag di \textit{close-on-exec} sul file descriptor sottostante (si ricordi
+quanto spiegato in sez.~\ref{sec:file_open_close}).
 
 Lo \textit{stream} restituito da \func{popen} è identico a tutti gli effetti
 ai \textit{file stream} visti in sez.~\ref{sec:files_std_interface}, anche se
@@ -514,10 +514,10 @@ a quello illustrato per le \textit{pipe} in sez.~\ref{sec:ipc_pipes}.
 
 Abbiamo già trattato in sez.~\ref{sec:file_mknod} le funzioni \func{mknod} e
 \func{mkfifo} che permettono di creare una \textit{fifo}. Per utilizzarne una
-un processo non avrà che da aprire il relativo \index{file!speciali} file
-speciale o in lettura o scrittura; nel primo caso il processo sarà collegato
-al capo di uscita della \textit{fifo}, e dovrà leggere, nel secondo al capo di
-ingresso, e dovrà scrivere.
+un processo non avrà che da aprire il relativo file speciale o in lettura o
+scrittura; nel primo caso il processo sarà collegato al capo di uscita della
+\textit{fifo}, e dovrà leggere, nel secondo al capo di ingresso, e dovrà
+scrivere.
 
 Il kernel alloca un singolo buffer per ciascuna \textit{fifo} che sia stata
 aperta, e questa potrà essere acceduta contemporaneamente da più processi, sia
@@ -821,21 +821,21 @@ presenta il problema della unidirezionalità del flusso dei dati, è quello dei
 cosiddetti \textsl{socket locali} (o \textit{Unix domain socket}).  Tratteremo
 in generale i socket in cap.~\ref{cha:socket_intro}, nell'ambito
 dell'interfaccia che essi forniscono per la programmazione di rete, e vedremo
-anche (in~sez.~\ref{sec:sock_sa_local}) come si possono utilizzare i
-\index{file!speciali} file speciali di tipo socket, analoghi a quelli
-associati alle \textit{fifo} (si rammenti sez.~\ref{sec:file_file_types}) cui
-si accede però attraverso quella medesima interfaccia; vale però la pena
-esaminare qui una modalità di uso dei socket locali che li rende
-sostanzialmente identici ad una \textit{pipe} bidirezionale.
+anche (in~sez.~\ref{sec:sock_sa_local}) come si possono utilizzare i file
+speciali di tipo socket, analoghi a quelli associati alle \textit{fifo} (si
+rammenti sez.~\ref{sec:file_file_types}) cui si accede però attraverso quella
+medesima interfaccia; vale però la pena esaminare qui una modalità di uso dei
+socket locali che li rende sostanzialmente identici ad una \textit{pipe}
+bidirezionale.
 
 La funzione di sistema \funcd{socketpair}, introdotta da BSD ma supportata in
 genere da qualunque sistema che fornisca l'interfaccia dei socket ed inclusa
 in POSIX.1-2001, consente infatti di creare una coppia di file descriptor
 connessi fra loro (tramite un socket, appunto) senza dover 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 è:
+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{funcproto}{
 \fhead{sys/types.h} 
@@ -1075,8 +1075,7 @@ direttamente (in lettura o scrittura) all'oggetto. In tal caso lo schema dei
 controlli è simile a quello dei file, ed avviene secondo questa sequenza:
 \begin{itemize*}
 \item se il processo ha i privilegi di amministratore (più precisamente la
-  capacità \itindex{capability} \const{CAP\_IPC\_OWNER}) l'accesso è sempre
-  consentito.
+  capacità \const{CAP\_IPC\_OWNER}) l'accesso è sempre consentito.
 \item se l'\ids{UID} effettivo del processo corrisponde o al valore del campo
   \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario
   in \var{mode} è appropriato\footnote{per appropriato si intende che è
@@ -1451,9 +1450,9 @@ per \param{cmd} sono:
   occorre essere il proprietario o il creatore della coda, oppure
   l'amministratore e lo stesso vale per \var{msg\_qbytes}. Infine solo
   l'amministratore (più precisamente un processo con la capacità
-  \itindex{capability} \const{CAP\_IPC\_RESOURCE}) ha la facoltà di
-  incrementarne il valore a limiti superiori a \const{MSGMNB}. Se eseguita con
-  successo la funzione aggiorna anche il campo \var{msg\_ctime}.
+  \const{CAP\_IPC\_RESOURCE}) ha la facoltà di incrementarne il valore a
+  limiti superiori a \const{MSGMNB}. Se eseguita con successo la funzione
+  aggiorna anche il campo \var{msg\_ctime}.
 \end{basedescript}
 
 A questi tre valori, che sono quelli previsti dallo standard, su Linux se ne
@@ -2423,8 +2422,7 @@ referenziata tramite i campi \var{sem\_pending} e \var{sem\_pending\_last} di
 operazioni richieste (nel campo \var{sops}, che è un puntatore ad una
 struttura \struct{sembuf}) e al processo corrente (nel campo \var{sleeper})
 poi quest'ultimo viene messo stato di attesa e viene invocato lo
-\itindex{scheduler} \textit{scheduler} per passare all'esecuzione di un altro
-processo.
+\textit{scheduler} per passare all'esecuzione di un altro processo.
 
 Se invece tutte le operazioni possono avere successo queste vengono eseguite
 immediatamente, dopo di che il kernel esegue una scansione della coda di
@@ -2591,8 +2589,8 @@ creazione del segmento usando una \itindex{huge~page} \textit{huge page}, le
 pagine di memoria di grandi dimensioni introdotte con il kernel 2.6 per
 ottimizzare le prestazioni nei sistemi più recenti che hanno grandi quantità
 di memoria. L'operazione è privilegiata e richiede che il processo abbia la
-\itindex{capability} \textit{capability} \const{CAP\_IPC\_LOCK}. Questa
-funzionalità è specifica di Linux e non è portabile.
+\textit{capability} \const{CAP\_IPC\_LOCK}. Questa funzionalità è specifica di
+Linux e non è portabile.
 
 Il secondo flag aggiuntivo, introdotto a partire dal kernel 2.6.15, è
 \const{SHM\_NORESERVE}, ed ha lo stesso scopo del flag \const{MAP\_NORESERVE}
@@ -2776,13 +2774,12 @@ si ha a cuore la portabilità. Questi comandi aggiuntivi sono:
 \begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
 \item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory
     locking} sul segmento di memoria condivisa, impedendo che la memoria usata
-  per il segmento venga salvata su disco dal meccanismo della
-  \index{memoria~virtuale} memoria virtuale. Come illustrato in
-  sez.~\ref{sec:proc_mem_lock} fino al kernel 2.6.9 solo l'amministratore
-  poteva utilizzare questa capacità,\footnote{che richiedeva la
-    \textit{capability} \const{CAP\_IPC\_LOCK}.} a partire dal dal kernel
-  2.6.10 anche gli utenti normali possono farlo fino al limite massimo
-  determinato da \const{RLIMIT\_MEMLOCK} (vedi
+  per il segmento venga salvata su disco dal meccanismo della memoria
+  virtuale. Come illustrato in sez.~\ref{sec:proc_mem_lock} fino al kernel
+  2.6.9 solo l'amministratore poteva utilizzare questa capacità,\footnote{che
+    richiedeva la \textit{capability} \const{CAP\_IPC\_LOCK}.} a partire dal
+  dal kernel 2.6.10 anche gli utenti normali possono farlo fino al limite
+  massimo determinato da \const{RLIMIT\_MEMLOCK} (vedi
   sez.~\ref{sec:sys_resource_limit}).
 \item[\const{SHM\_UNLOCK}] Disabilita il \itindex{memory~locking}
   \textit{memory locking} sul segmento di memoria condivisa.  Fino al kernel
@@ -3069,12 +3066,11 @@ con un messaggio di errore.
 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 \index{directory~di~lavoro} directory di lavoro del programma nella
-directory da tenere sotto controllo, in vista del successivo uso della
-funzione \func{daemon}. Si noti come si è potuta fare questa scelta,
-nonostante le indicazioni illustrate in sez.~\ref{sec:sess_daemon}, per il
-particolare scopo del programma, che necessita comunque di restare all'interno
-di una directory.
+la directory di lavoro del programma nella directory da tenere sotto
+controllo, in vista del successivo uso della funzione \func{daemon}. Si noti
+come si è potuta fare questa scelta, nonostante le indicazioni illustrate in
+sez.~\ref{sec:sess_daemon}, per il particolare scopo del programma, che
+necessita comunque di restare all'interno di una directory.
 
 Infine (\texttt{\small 27-29}) si installano i gestori per i vari segnali di
 terminazione che, avendo a che fare con un programma che deve essere eseguito
@@ -3103,9 +3099,9 @@ intercomunicazione il programma entra nel ciclo principale (\texttt{\small
 Il primo passo (\texttt{\small 41}) è eseguire \func{daemon} per proseguire
 con l'esecuzione in background come si conviene ad un programma demone; si
 noti che si è mantenuta, usando un valore non nullo del primo argomento, la
-\index{directory~di~lavoro} directory di lavoro corrente.  Una volta che il
-programma è andato in background l'esecuzione prosegue all'interno di un ciclo
-infinito (\texttt{\small 42-48}).
+directory di lavoro corrente.  Una volta che il programma è andato in
+background l'esecuzione prosegue all'interno di un ciclo infinito
+(\texttt{\small 42-48}).
 
 Si inizia (\texttt{\small 43}) bloccando il mutex con \func{MutexLock} per
 poter accedere alla memoria condivisa (la funzione si bloccherà
@@ -3553,6 +3549,11 @@ sez.~\ref{sec:ipc_sysv_shm} che possa restituisca i risultati via rete.
 % 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
 
+% TODO: con il kernel 3.17 è stata introdotta una fuunzionalità di
+% sigillatura dei file mappati in memoria e la system call memfd
+% (capire se va messo qui o altrove) vedi: http://lwn.net/Articles/593918/
+
+
 \section{L'intercomunicazione fra processi di POSIX}
 \label{sec:ipc_posix}
 
@@ -3786,9 +3787,8 @@ dei limiti sono:
   valore massimo è \const{HARD\_MAX} che vale \code{(131072/sizeof(void *))},
   ed il valore minimo 1 (ma era 10 per i kernel precedenti il 2.6.28). Questo
   limite viene ignorato per i processi con privilegi amministrativi (più
-  precisamente con la \itindex{capability} \textit{capability}
-  \const{CAP\_SYS\_RESOURCE}) ma \const{HARD\_MAX} resta comunque non
-  superabile.
+  precisamente con la \textit{capability} \const{CAP\_SYS\_RESOURCE}) ma
+  \const{HARD\_MAX} resta comunque non superabile.
 
 \item[\sysctlfile{fs/mqueue/msgsize\_max}] Indica il valore massimo della
   dimensione in byte di un messaggio sulla coda ed agisce come limite
@@ -3796,14 +3796,14 @@ dei limiti sono:
   suo valore di default è 8192.  Il valore massimo è 1048576 ed il valore
   minimo 128 (ma per i kernel precedenti il 2.6.28 detti limiti erano
   rispettivamente \const{INT\_MAX} e 8192). Questo limite viene ignorato dai
-  processi con privilegi amministrativi (con la \itindex{capability}
-  \textit{capability} \const{CAP\_SYS\_RESOURCE}).
+  processi con privilegi amministrativi (con la \textit{capability}
+  \const{CAP\_SYS\_RESOURCE}).
 
 \item[\sysctlfile{fs/mqueue/queues\_max}] Indica il numero massimo di code di
   messaggi creabili in totale sul sistema, il valore di default è 256 ma si
   può usare un valore qualunque fra $0$ e \const{INT\_MAX}. Il limite non
   viene applicato ai processi con privilegi amministrativi (cioè con la
-  \itindex{capability} \textit{capability} \const{CAP\_SYS\_RESOURCE}).
+  \textit{capability} \const{CAP\_SYS\_RESOURCE}).
 
 \end{basedescript}
 
@@ -5082,10 +5082,10 @@ testo alla terminazione di quest'ultimo.
 % LocalWords:  SysV capability short RESOURCE INFO UNDEFINED EFBIG semtimedop
 % LocalWords:  scan HUGETLB huge page NORESERVE copy RLIMIT MEMLOCK REMAP UTC
 % LocalWords:  readmon Hierarchy defaults queues MSGQUEUE effective fstat
+% LocalWords:  fchown fchmod Epoch January
 
 
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "gapil"
 %%% End: 
-% LocalWords:  fchown fchmod Epoch January