\var{l\_start}$-1$, mentre per un valore positivo l'intervallo va da
\var{l\_start} a \var{l\_start}$+$\var{l\_len}$-1$. Si può però usare un
valore negativo soltanto se l'inizio della regione indicata non cade prima
-dell'inizio del file, con un valore positivo invece si può anche indicare una
-regione che eccede la dimensione corrente del file, e questa verrà coperta in
-una sua futura estensione.
+dell'inizio del file, mentre come accennato con un valore positivo si
+può anche indicare una regione che eccede la dimensione corrente del file.
Il tipo di \textit{file lock} richiesto viene specificato dal campo
\var{l\_type}, esso può assumere i tre valori definiti dalle costanti
controlla (\texttt{\small 27--31}) il valore di \var{cmd} per determinare se
si vuole effettuare una chiamata bloccante o meno, reimpostandone il valore
opportunamente, dopo di che a seconda del tipo di blocco al valore viene
-aggiunta la relativa opzione (con un OR aritmetico, dato che \func{flock}
+aggiunta la relativa opzione, con un OR aritmetico, dato che \func{flock}
vuole un argomento \param{operation} in forma di maschera binaria. Nel caso
invece che si sia scelta la semantica POSIX le operazioni sono molto più
-immediate, si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
-esegue (\texttt{\small 41}).
+immediate si prepara (\texttt{\small 36--40}) la struttura per il lock, e lo
+si esegue (\texttt{\small 41}).
In entrambi i casi dopo aver richiesto il blocco viene controllato il
risultato uscendo (\texttt{\small 44--46}) in caso di errore, o stampando un
\end{Console}
%$
che ci mostra come i due tipi di blocco siano assolutamente indipendenti; per
-questo motivo occorre sempre tenere presente quale fra le due semantiche
-disponibili stanno usando i programmi con cui si interagisce, dato che i
+questo motivo occorre sempre tenere presente quale, fra le due semantiche
+disponibili, stanno usando i programmi con cui si interagisce, dato che i
blocchi applicati con l'altra non avrebbero nessun effetto.
% \subsection{La funzione \func{lockf}}
sovrappone ad una che è già stata bloccata da un altro processo; in caso di
sovrapposizione con un altro blocco già ottenuto le sezioni vengono unite.
\item[\const{F\_TLOCK}] Richiede un \textit{exclusive lock}, in maniera
- identica a\const{F\_LOCK} ma in caso di indisponibilità non blocca il
+ identica a \const{F\_LOCK}, ma in caso di indisponibilità non blocca il
processo restituendo un errore di \errval{EAGAIN}.
\item[\const{F\_ULOCK}] Rilascia il blocco sulla sezione indicata, questo può
anche causare la suddivisione di una sezione bloccata in precedenza nelle
La funzione è semplicemente una diversa interfaccia al \textit{file locking}
POSIX ed è realizzata utilizzando \func{fcntl}; pertanto la semantica delle
operazioni è la stessa di quest'ultima e quindi la funzione presenta lo stesso
-comportamento riguardo gli effetti della chiusura dei file, degli effetti sui
-file duplicati e nel passaggio attraverso \func{fork} ed \func{exec}. Per
-questo motivo la funzione non è affatto equivalente a \func{flock} e può
-essere usata senza interferenze insieme a quest'ultima.
+comportamento riguardo gli effetti della chiusura dei file, ed il
+comportamento sui file duplicati e nel passaggio attraverso \func{fork} ed
+\func{exec}. Per questo stesso motivo la funzione non è equivalente a
+\func{flock} e può essere usata senza interferenze insieme a quest'ultima.
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 \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
-quest'ultimo venga attivato per il file 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}.\footnote{un lettore attento potrebbe ricordare quanto detto in
- sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
- cancellato (come misura di sicurezza) quando di scrive su un file, questo
- non vale quando esso viene utilizzato per attivare il \textit{mandatory
- locking}.}
+utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid} dei permessi dei
+file. Se si ricorda quanto esposto in sez.~\ref{sec:file_special_perm}), esso
+viene di norma 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 quest'ultimo venga attivato per il file 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}.\footnote{un lettore attento potrebbe ricordare
+ quanto detto in sez.~\ref{sec:file_perm_management} e cioè che il bit
+ \acr{sgid} viene cancellato (come misura di sicurezza) quando di scrive su
+ un file, questo non vale quando esso viene utilizzato per attivare il
+ \textit{mandatory locking}.}
L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
bloccare completamente un server NFS richiedendo una lettura su un file su cui
è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
locking} è di norma disabilitata, e deve essere attivata filesystem per
-filesystem in fase di montaggio (specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}), o con l'opzione
-\code{-o mand} per il comando omonimo).
+filesystem in fase di montaggio, specificando l'apposita opzione di
+\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}, o con l'opzione
+\code{-o mand} per il comando omonimo.
Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
attuale delle cose è sconsigliabile fare affidamento sul \textit{mandatory
locking}.
-
\itindend{file~locking}
\itindend{mandatory~locking}
Abbiamo visto in sez.~\ref{sec:sig_gen_beha}, affrontando la suddivisione fra
\textit{fast} e \textit{slow} \textit{system call},\index{system~call~lente}
-che in certi casi le funzioni di I/O possono bloccarsi
-indefinitamente.\footnote{si ricordi però che questo può accadere solo per le
- pipe, i socket ed alcuni file di dispositivo\index{file!di~dispositivo}; sui
- file normali le funzioni di lettura e scrittura ritornano sempre subito.}
-Ad esempio le operazioni di lettura possono bloccarsi quando non ci sono dati
-disponibili sul descrittore su cui si sta operando.
-
-Questo comportamento causa uno dei problemi più comuni che ci si trova ad
-affrontare nelle operazioni di I/O, che si verifica quando si deve operare con
-più file descriptor eseguendo funzioni che possono bloccarsi senza che sia
-possibile prevedere quando questo può avvenire (il caso più classico è quello
-di un server in attesa di dati in ingresso da vari client). Quello che può
-accadere è di restare bloccati nell'eseguire una operazione su un file
-descriptor che non è ``\textsl{pronto}'', quando ce ne potrebbe essere un
-altro disponibile. Questo comporta nel migliore dei casi una operazione
-ritardata inutilmente nell'attesa del completamento di quella bloccata, mentre
-nel peggiore dei casi (quando la conclusione della operazione bloccata dipende
-da quanto si otterrebbe dal file descriptor ``\textsl{disponibile}'') si
-potrebbe addirittura arrivare ad un \itindex{deadlock} \textit{deadlock}.
+che in certi casi le funzioni di I/O eseguite su un file descritor possono
+bloccarsi indefinitamente. Questo non avviene mai per i file normali, per i
+quali le funzioni di lettura e scrittura ritornano sempre subito, ma può
+avvenire per alcuni \index{file!di~dispositivo} file di dispositivo, come ad
+esempio una seriale, o con l'uso di file descriptor collegati a meccanismi di
+intercomunicazione come le \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}) ed i
+socket (vedi sez.~\ref{sec:sock_socket_def}). In casi come questi ad esempio
+una operazione di lettura potrebbe bloccarsi se non ci sono dati disponibili
+sul descrittore su cui la si sta effettuando.
+
+Questo comportamento è alla radice di una delle problematiche più comuni che
+ci si trova ad affrontare nelle operazioni di I/O, la necessità di operare su
+su più file descriptor eseguendo funzioni che possono bloccarsi
+indefinitamente senza che sia possibile prevedere quando questo può avvenire;
+un caso classico è quello di un server di rete (tratteremo la problematica in
+dettaglio nella seconda parte della guida) in attesa di dati in ingresso
+prevenienti da vari client.
+
+In un caso di questo tipo, se si andasse ad operare sui vari file descriptor
+aperti uno dopo l'altro, potrebbe accadere di restare bloccati nell'eseguire
+una lettura su uno di quelli che non è ``\textsl{pronto}'', quando ce ne
+potrebbe essere un altro con dati disponibili. Questo comporta nel migliore
+dei casi una operazione ritardata inutilmente nell'attesa del completamento di
+quella bloccata, mentre nel peggiore dei casi (quando la conclusione della
+operazione bloccata dipende da quanto si otterrebbe dal file descriptor
+``\textsl{disponibile}'') si potrebbe addirittura arrivare ad un
+\itindex{deadlock} \textit{deadlock}.
Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile
prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file
projects / gapil.git / commitdiff