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
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
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
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}
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 è
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
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}
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
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à
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
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}
% 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
projects / gapil.git / blobdiff