\itindex{self-pipe trick} \textit{self-pipe trick}, che consiste nell'aprire
una pipe (vedi sez.~\ref{sec:ipc_pipes}) ed usare \func{select} sul capo in
lettura della stessa, e indicare l'arrivo di un segnale scrivendo sul capo
- in scrittura all'interno del manipolatore; in questo modo anche se il
- segnale va perso prima della chiamata di \func{select} questa lo riconoscerà
- comunque dalla presenza di dati sulla pipe.} ribloccandolo non appena essa
-ritorna, così che il precedente codice potrebbe essere riscritto nel seguente
-modo:
+ in scrittura all'interno del gestore dello stesso; in questo modo anche se
+ il segnale va perso prima della chiamata di \func{select} questa lo
+ riconoscerà comunque dalla presenza di dati sulla pipe.} ribloccandolo non
+appena essa ritorna, così che il precedente codice potrebbe essere riscritto
+nel seguente modo:
\includecodesnip{listati/pselect_norace.c}
in questo caso utilizzando \var{oldmask} durante l'esecuzione di
\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
in genere è opportuno farlo, come in precedenza, per utilizzare segnali
- real-time.} e si è installato il manipolatore del segnale con
-\const{SA\_SIGINFO} si riceverà nel campo \var{si\_fd} della struttura
-\struct{siginfo\_t} il valore del file descriptor del file sul quale è stato
-compiuto l'accesso; in questo modo un processo può mantenere anche più di un
-\textit{file lease}.
+ real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
+si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
+valore del file descriptor del file sul quale è stato compiuto l'accesso; in
+questo modo un processo può mantenere anche più di un \textit{file lease}.
Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
directory, o di uno qualunque dei file in essa contenuti, viene modificato.
Come per i \textit{file lease} la notifica avviene di default attraverso il
segnale \const{SIGIO}, ma questo può essere modificato e si può ottenere nel
-manipolatore il file descriptor che è stato modificato dal contenuto della
+gestore il file descriptor che è stato modificato dal contenuto della
struttura \struct{siginfo\_t}.
\index{file!lease|)}
Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
la memoria reale è divisa in pagine: ogni processo vede la sua memoria
attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
- questi segmenti il kernel mantiene nella \itindex{page~table}\textit{page
+ questi segmenti il kernel mantiene nella \itindex{page~table} \textit{page
table} la mappatura sulle pagine di memoria reale, ed le modalità di
accesso (lettura, esecuzione, scrittura); una loro violazione causa quella
che si chiama una \textit{segment violation}, e la relativa emissione del
kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
- i lock creati con la semantica BSD.} alla voce nella \textit{file table} da
-cui si è richiesto il lock, che così ne identifica il titolare.
+ i lock creati con la semantica BSD.} alla voce nella \itindex{file~table}
+\textit{file table} da cui si è richiesto il lock, che così ne identifica il
+titolare.
Questa struttura prevede che, quando si richiede la rimozione di un file lock,
il kernel acconsenta solo se la richiesta proviene da un file descriptor che
-fa riferimento ad una voce nella file table corrispondente a quella registrata
-nel lock. Allora se ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
-ereditati in un processo figlio puntano sempre alla stessa voce nella file
-table, si può capire immediatamente quali sono le conseguenze nei confronti
-delle funzioni \func{dup} e \func{fork}.
+fa riferimento ad una voce nella \itindex{file~table} \textit{file table}
+corrispondente a quella registrata nel lock. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_sharing}, e cioè che i
+file descriptor duplicati e quelli ereditati in un processo figlio puntano
+sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può
+capire immediatamente quali sono le conseguenze nei confronti delle funzioni
+\func{dup} e \func{fork}.
Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
-descriptor che fanno riferimento alla stessa voce nella file table, anche se
-questo è diverso da quello con cui lo si è creato,\footnote{attenzione, questo
- non vale se il file descriptor fa riferimento allo stesso file, ma
- attraverso una voce diversa della file table, come accade tutte le volte che
- si apre più volte lo stesso file.} o se si esegue la rimozione in un
-processo figlio; inoltre una volta tolto un file lock, la rimozione avrà
-effetto su tutti i file descriptor che condividono la stessa voce nella file
-table, e quindi, nel caso di file descriptor ereditati attraverso una
-\func{fork}, anche su processi diversi.
+descriptor che fanno riferimento alla stessa voce nella \itindex{file~table}
+\textit{file table}, anche se questo è diverso da quello con cui lo si è
+creato,\footnote{attenzione, questo non vale se il file descriptor fa
+ riferimento allo stesso file, ma attraverso una voce diversa della
+ \itindex{file~table} \textit{file table}, come accade tutte le volte che si
+ apre più volte lo stesso file.} o se si esegue la rimozione in un processo
+figlio; inoltre una volta tolto un file lock, la rimozione avrà effetto su
+tutti i file descriptor che condividono la stessa voce nella
+\itindex{file~table} \textit{file table}, e quindi, nel caso di file
+descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
Infine, per evitare che la terminazione imprevista di un processo lasci attivi
dei file lock, quando un file viene chiuso il kernel provveda anche a
rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
presente cosa succede quando si hanno file descriptor duplicati; in tal caso
infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
-che non viene rilasciata la relativa voce nella file table; e questo avverrà
-solo quando tutti i file descriptor che fanno riferimento alla stessa voce
-sono stati chiusi. Quindi, nel caso ci siano duplicati o processi figli che
-mantengono ancora aperto un file descriptor, il lock non viene rilasciato.
+che non viene rilasciata la relativa voce nella \itindex{file~table}
+\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
+fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
+siano duplicati o processi figli che mantengono ancora aperto un file
+descriptor, il lock non viene rilasciato.
Si tenga presente infine che \func{flock} non è in grado di funzionare per i
file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
usato.} il lock è sempre associato all'inode\index{inode}, solo che in
questo caso la titolarità non viene identificata con il riferimento ad una
-voce nella file table, ma con il valore del \acr{pid} del processo.
+voce nella \itindex{file~table} \textit{file table}, ma con il valore del
+\acr{pid} del processo.
Quando si richiede un lock il kernel effettua una scansione di tutti i lock
presenti sul file\footnote{scandisce cioè la \itindex{linked~list}
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_suid_sgid}), esso viene di norma
+quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
utilizzato per cambiare il group-ID 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
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_chmod} 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}.}
+ 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 lock; pertanto un processo
projects / gapil.git / blobdiff