error}\\
\hline
\end{tabular}
- \caption{Costanti definite in \file{unistd.h} per i file standard aperti
+ \caption{Costanti definite in \headfile{unistd.h} per i file standard aperti
alla creazione di ogni processo.}
\label{tab:file_std_files}
\end{table}
#define _XOPEN_SOURCE 500
\end{verbatim}
e si ricordi di definire questa macro prima dell'inclusione del file di
-dichiarazioni \file{unistd.h}.
+dichiarazioni \headfile{unistd.h}.
Un problema che si pone con l'uso della funzione \func{open}, così come per
molte altre funzioni che accettano come argomenti dei pathname relativi, è
-che, quando un pathname relativo non fa riferimento alla directory di lavoro
-corrente, è possibile che alcuni dei suoi componenti vengano modificati in
-parallelo alla chiamata a \func{open}, e questo lascia aperta la possibilità
-di una \itindex{race~condition} \textit{race condition}.
-
-Inoltre come già accennato, la directory di lavoro corrente è una proprietà
-del singolo processo; questo significa che quando si lavora con i
-\itindex{thread} \textit{thread} essa sarà la stessa per tutti, ma esistono
-molti casi in cui sarebbe invece utile che ogni singolo \itindex{thread}
-\textit{thread} avesse la sua directory di lavoro.
+che, quando un pathname relativo non fa riferimento alla
+\index{directory~di~lavoro} directory di lavoro corrente, è possibile che
+alcuni dei suoi componenti vengano modificati in parallelo alla chiamata a
+\func{open}, e questo lascia aperta la possibilità di una
+\itindex{race~condition} \textit{race condition}.
+
+Inoltre come già accennato, la \index{directory~di~lavoro} directory di lavoro
+corrente è una proprietà del singolo processo; questo significa che quando si
+lavora con i \itindex{thread} \textit{thread} essa sarà la stessa per tutti,
+ma esistono molti casi in cui sarebbe invece utile che ogni singolo
+\itindex{thread} \textit{thread} avesse la sua \index{directory~di~lavoro}
+directory di lavoro.
Per risolvere questi problemi, riprendendo una interfaccia già presente in
Solaris, a fianco delle normali funzioni che operano sui file (come
seguito, dopo di che si dovrà passare il relativo file descriptor alle varie
funzioni che useranno quella directory come punto di partenza per la
risoluzione.\footnote{in questo modo, anche quando si lavora con i
- \itindex{thread} \textit{thread}, si può mantenere una directory di lavoro
- diversa per ciascuno di essi.}
+ \itindex{thread} \textit{thread}, si può mantenere una
+ \index{directory~di~lavoro} directory di lavoro diversa per ciascuno di
+ essi.}
Questo metodo, oltre a risolvere i problemi di \itindex{race~condition}
\textit{race condition}, consente anche di ottenere aumenti di prestazioni
\funcdecl{int openat(int dirfd, const char *pathname, int flags, mode\_t
mode))}
- Apre un file usando come directory di lavoro corrente \param{dirfd}.
+ Apre un file usando come directory di \index{directory~di~lavoro} lavoro
+ corrente \param{dirfd}.
\bodydesc{la funzione restituisce gli stessi valori e gli stessi codici di
errore di \func{open}, ed in più:
directory indicata da \param{dirfd}; qualora invece si usi un pathname
assoluto \param{dirfd} verrà semplicemente ignorato. Infine se per
\param{dirfd} si usa il valore speciale \const{AT\_FDCWD},\footnote{questa,
- come le altre costanti \texttt{AT\_*}, è definita in \texttt{fcntl.h},
+ come le altre costanti \texttt{AT\_*}, è definita in \headfile{fcntl.h},
pertanto se la si vuole usare occorrerà includere comunque questo file,
anche per le funzioni che non sono definite in esso.} la risoluzione sarà
-effettuata rispetto alla directory di lavoro corrente del processo.
+effettuata rispetto alla directory di \index{directory~di~lavoro} lavoro
+corrente del processo.
Così come il comportamento, anche i valori di ritorno e le condizioni di
errore delle nuove funzioni sono gli stessi delle funzioni classiche, agli
casi esso può fornire ulteriori indicazioni per modificare il comportamento
delle funzioni, \param{flags} deve comunque essere passato come maschera
binaria, ed impostato usando i valori delle appropriate costanti
-\texttt{AT\_*}, definite in \texttt{fcntl.h}.
+\texttt{AT\_*}, definite in \headfile{fcntl.h}.
Come esempio di questo secondo tipo di funzioni possiamo considerare
\funcd{fchownat}, che può essere usata per sostituire sia \func{chown}
In questo caso il valore di \param{flags} stabilisce il comportamento della
funzione quando la si applica ad un link simbolico, e l'unico valore
-utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \texttt{fcntl.h} è
+utilizzabile è \const{AT\_SYMLINK\_NOFOLLOW}\footnote{in \headfile{fcntl.h} è
definito anche \const{AT\_SYMLINK\_FOLLOW}, che richiede di dereferenziare i
link simbolici, essendo questo però il comportamento adottato per un valore
nullo di \param{flags} questo valore non viene mai usato.} che se impostato
il comportamento rispetto a quello ordinario di \func{access}. In questo caso
esso può essere specificato come maschera binaria di due valori:
\begin{basedescript}{\desclabelwidth{3.0cm}}
-\item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo
+\item[\const{AT\_EACCES}] se impostato \funcd{faccessat} esegue il controllo
dei permessi usando l'\ids{UID} effettivo invece di quello reale (il
comportamento di default, che riprende quello di \func{access}).
\item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue
queste costanti sono poste rispettivamente ai valori 0, 1 e 2.} Per questo
motivo il valore della modalità di accesso corrente si ottiene eseguendo un
AND binario del valore di ritorno di \func{fcntl} con la maschera
-\const{O\_ACCMODE} (anch'essa definita in \file{fcntl.h}), che estrae i bit di
-accesso dal \textit{file status flag}.
+\const{O\_ACCMODE} (anch'essa definita in \headfile{fcntl.h}), che estrae i
+bit di accesso dal \textit{file status flag}.
In generale ogni dispositivo ha un suo insieme di operazioni specifiche
effettuabili attraverso \func{ioctl}, tutte queste sono definite nell'header
-file \file{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui fanno
-riferimento. Infatti anche se in genere i valori di \param{request} sono
+file \headfile{sys/ioctl.h}, e devono essere usate solo sui dispositivi cui
+fanno riferimento. Infatti anche se in genere i valori di \param{request} sono
opportunamente differenziati a seconda del dispositivo\footnote{il kernel usa
un apposito \textit{magic number} per distinguere ciascun dispositivo nella
definizione delle macro da usare per \param{request}, in modo da essere
% LocalWords: Drepper path dirfd faccessat unlinkat access fchmodat chmod Di
% LocalWords: fchownat chown fstatat futimesat utimes linkat mknodat mknod uid
% LocalWords: readlinkat readlink renameat rename symlinkat symlink unlink gid
-% LocalWords: mkfifoat mkfifo FDCWD EACCESS dereferenziazione rmdir REMOVEDIR
+% LocalWords: mkfifoat mkfifo FDCWD dereferenziazione rmdir REMOVEDIR
% LocalWords: epoll lsattr chattr FIOQSIZE ATFILE lutimes utimensat lchown
% LocalWords: lstat owner FOLLOW
projects / gapil.git / blobdiff