X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=fileadv.tex;h=02f0b9f80c90f35176a6d6a278b1a8b74a31a62d;hb=fd4e2fd24a218ef56953fd5a58d0b3c0bee8acb7;hp=d3c9061f7fbe1af01d4b7eb54f850447262d3feb;hpb=f10ada1c0b49d3bbdb22dbe3a61e27914584d70b;p=gapil.git

diff --git a/fileadv.tex b/fileadv.tex
index d3c9061..02f0b9f 100644
--- a/fileadv.tex
+++ b/fileadv.tex
@@ -385,7 +385,7 @@ riportate in tab.~\ref{tab:file_flock_type}, che permettono di richiedere
 rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la
 rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid}
 viene usato solo in caso di lettura, quando si chiama \func{fcntl} con
-\const{F\_GETLK}, e riporta il \acr{pid} del processo che detiene il
+\const{F\_GETLK}, e riporta il \ids{PID} del processo che detiene il
 \textit{file lock}.
 
 Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione
@@ -462,14 +462,14 @@ fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo
 di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si
   sono evidenziati solo i campi di \struct{file\_lock} significativi per la
   semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al
-  \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene
+  \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene
   bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}.  La struttura è
   comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è
   impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
   usato.} il blocco è sempre associato \itindex{inode} all'inode, solo che in
 questo caso la titolarità non viene identificata con il riferimento ad una
 voce nella \itindex{file~table} \textit{file table}, ma con il valore del
-\acr{pid} del processo.
+\ids{PID} del processo.
 
 \begin{figure}[!htb]
   \centering \includegraphics[width=12cm]{img/file_posix_lock}
@@ -488,19 +488,19 @@ una già bloccata, in caso affermativo decide in base al tipo di blocco, in
 caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
 
 Nel caso di rimozione invece questa viene effettuata controllando che il
-\acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco.
+\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
 Questa diversa modalità ha delle conseguenze precise riguardo il comportamento
 dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock}
 POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo
-figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una
-\func{exec} in quanto il \acr{pid} resta lo stesso.  Questo comporta che, al
+figlio avrà un \ids{PID} diverso, mentre passa indenne attraverso una
+\func{exec} in quanto il \ids{PID} resta lo stesso.  Questo comporta che, al
 contrario di quanto avveniva con la semantica BSD, quando un processo termina
 tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati.
 
 La seconda conseguenza è che qualunque file descriptor che faccia riferimento
 allo stesso file (che sia stato ottenuto con una \func{dup} o con una
 \func{open} in questo caso non fa differenza) può essere usato per rimuovere
-un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da
+un blocco, dato che quello che conta è solo il \ids{PID} del processo. Da
 questo deriva una ulteriore sottile differenza di comportamento: dato che alla
 chiusura di un file i blocchi ad esso associati vengono rimossi, nella
 semantica POSIX basterà chiudere un file descriptor qualunque per cancellare
@@ -508,11 +508,11 @@ tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi
 fossero stati creati usando altri file descriptor che restano aperti.
 
 Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del
-\acr{pid} del processo, possiamo anche prendere in considerazione un altro
+\ids{PID} del processo, possiamo anche prendere in considerazione un altro
 degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si
 richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno
 stesso processo. Siccome il controllo, come nel caso della rimozione, si basa
-solo sul \acr{pid} del processo che chiama la funzione, queste richieste
+solo sul \ids{PID} del processo che chiama la funzione, queste richieste
 avranno sempre successo.
 
 Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non
@@ -811,7 +811,7 @@ opportune verifiche nei processi, questo verrebbe comunque rispettato.
 Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
 utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
 quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
-utilizzato per cambiare il \acr{gid} effettivo con cui viene eseguito un
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
 programma, ed è pertanto sempre associato alla presenza del permesso di
 esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
 esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
@@ -2677,7 +2677,7 @@ Si tenga presente che un processo può mantenere solo un tipo di \textit{lease}
 su un file, e che un \textit{lease} può essere ottenuto solo su file di dati
 (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato
 può ottenere un \textit{lease} soltanto per un file appartenente ad un
-\acr{uid} corrispondente a quello del processo. Soltanto un processo con
+\ids{UID} corrispondente a quello del processo. Soltanto un processo con
 privilegi di amministratore (cioè con la \itindex{capabilities} capability
 \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
 \textit{lease} su qualunque file.