\item \macro{EROFS} \textit{Read-only file system}. il file risiede su un filesystem read-only.
\item \macro{EMLINK} \textit{Too many links}. Ci sono troppi link al file (il
numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
- \secref{sec:xxx_limits}).
+ \secref{sec:sys_limits}).
\item \macro{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
leggendo l'altro capo della pipe. Ogni funzione che restituisce questo
errore genera anche un segnale \macro{SIGPIPE}, la cui azione di default è
già.
\item \macro{EMLINK} ci sono troppi link al file \var{oldpath} (il
numero massimo è specificato dalla variabile \macro{LINK\_MAX}, vedi
- \secref{sec:xxx_limits}).
+ \secref{sec:sys_limits}).
\end{errlist}
ed inoltre \macro{EACCES}, \macro{ENAMETOOLONG}, \macro{ENOTDIR},
\macro{EFAULT}, \macro{ENOMEM}, \macro{EROFS}, \macro{ELOOP},
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \macro{PATH\_MAX} (di solito 256 byte, vedi
-\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
+\secref{sec:sys_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.
usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
-\secref{sec:file_xxx}).
+\secref{sec:file_noblocking}).
Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
Le periferiche infine vengono viste in genere attraverso un'interfaccia
astratta che permette di trattarle come fossero file, secondo il concetto per
cui \textit{everything is a file}, su cui torneremo in dettaglio in
-\capref{cha:files_intro}, (questo non è vero per le interfacce di rete, che
+\capref{cha:file_intro}, (questo non è vero per le interfacce di rete, che
hanno un'interfaccia diversa, ma resta valido il concetto generale che tutto
il lavoro di accesso e gestione a basso livello è effettuato dal kernel).
\begin{itemize*}
\item se la variabile è posta a zero gli errori vengono ignorati.
\item se è posta ad 1 viene stampato un avviso sullo \textit{standard error}
- (vedi \secref{sec:file_stdfiles}).
+ (vedi \secref{sec:file_std_stream}).
\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize*}
\textit{sibling}, questa è una delle relazioni usate nel \textsl{controllo di
sessione}, in cui si raggruppano i processi creati su uno stesso terminale,
o relativi allo stesso login. Torneremo su questo argomento in dettaglio in
-\secref{cap:session}, dove esamineremo gli altri identificativi associati ad
+\secref{cha:session}, dove esamineremo gli altri identificativi associati ad
un processo e le varie relazioni fra processi utilizzate per definire una
sessione.
controllo di accesso, che servono per determinare se il processo può o meno
eseguire le operazioni richieste, a seconda dei privilegi e dell'identità di
chi lo ha posto in esecuzione; su questi torneremo in dettagli più avanti in
-\secref{sec:proc_perm}.
+\secref{sec:proc_perms}.
\subsection{La funzione \func{fork}}
\secref{sec:file_work_dir}).
\item la maschera di creazione dei file (\var{umask}, vedi
\secref{sec:file_umask}) ed i \textit{lock} sui file (vedi
- \secref{sec:file_xxx}).
+ \secref{sec:file_locking}).
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
\secref{sec:sig_xxx}).
-\item i limiti sulle risorse (vedi \secref{sec:limits_xxx})..
+\item i limiti sulle risorse (vedi \secref{sec:sys_limits})..
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
- \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx})..
+ \var{tms\_cutime}, \var{tms\_ustime} (vedi \secref{sec:xxx_xxx}).
\end{itemize*}
Oltre a questo i segnali che sono stati settati per essere ignorati nel
-processo chiamante mantengono lo stesso settaggio pure nuovo programma, tutti
-gli altri segnali vengono settati alla loro azione di default. Un caso
-speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN}
+processo chiamante mantengono lo stesso settaggio pure nel nuovo programma,
+tutti gli altri segnali vengono settati alla loro azione di default. Un caso
+speciale è il segnale \macro{SIGCHLD} che, quando settato a \macro{SIG\_IGN},
può anche non essere resettato a \macro{SIG\_DFL} (si veda
\secref{sec:sig_xxx}).
La gestione dei file aperti dipende dal valore del flag di
\textit{close-on-exec} per ciascun file descriptor (si veda
-\secref{sec:file_xxx}); i file per cui è settato vengono chiusi, tutti gli
+\secref{sec:file_fcntl}); i file per cui è settato vengono chiusi, tutti gli
altri file restano aperti. Questo significa che il comportamento di default è
che i file restano aperti attraverso una \func{exec}, a meno di una chiamata
esplicita a \func{fcntl} che setti il suddetto flag.
Nel caso dell'interazione fra processi la situazione è molto più semplice, ed
occorre preoccuparsi della atomicità delle operazioni solo quando si ha a che
fare con meccanismi di intercomunicazione (che esamineremo in dettaglio in
-\capref{cha:ipc}) o nella operazioni con i file (vedremo alcuni esempi in
+\capref{cha:IPC}) o nella operazioni con i file (vedremo alcuni esempi in
\secref{sec:file_atomic}). In questi casi in genere l'uso delle appropriate
funzioni di libreria per compiere le operazioni necessarie è garanzia
sufficiente di atomicità in quanto le system call con cui esse sono realizzate
\item una richiesta dell'utente di terminare o fermare il programma. In genere
si realizza attraverso un segnale mandato dalla shell in corrispondenza
della pressione di tasti del terminale come 'ctrl-c' o 'ctrl-z'.
-\item l'esecuzione di una \texttt{kill} o di una \texttt{raise} da parte del
- processo stesso o di un'altro (solo nel caso della \texttt{kill}).
+\item l'esecuzione di una \func{kill} o di una \func{raise} da parte del
+ processo stesso o di un'altro (solo nel caso della \func{kill}).
\end{itemize}
Ciascuno di questi eventi (tranne gli ultimi due che sono controllati
input, scadenze di un timer, terminazione di processi figli.
Una richiesta esplicita significa l'uso di una chiamata di sistema (come
-\texttt{kill} o \texttt{raise}) per la generazione di un segnale, cosa che
+\func{kill} o \func{raise}) per la generazione di un segnale, cosa che
viene fatta usualmente dalla shell quando l'utente invoca la sequenza di tasti
di stop o di suspend, ma può essere pure inserita all'interno di un programma.
Una volta che il segnale viene notificato (che questo avvenga subito o dopo
una attesa più o meno lunga) viene eseguita l'azione specificata per detto
-segnale. Per alcuni segnali (\texttt{SIGKILL} e \texttt{SIGSTOP}) questa azione
+segnale. Per alcuni segnali (\macro{SIGKILL} e \macro{SIGSTOP}) questa azione
è fissa e non può essere cambiata, ma per tutti gli altri il programma può
specificare una scelta fra le tre seguenti:
\end{itemize}
Il programma può specificare queste scelte usano le due routine
-\texttt{signal} e \texttt{sigaction}; se si è installato un manipolatore sarà
+\func{signal} e \func{sigaction}; se si è installato un manipolatore sarà
quest'ultimo a intercettare il segnale ed ad essere eseguito, e mentre viene
eseguito (onde evitare race conditions) il segnale viene bloccato.
Quando un segnale termina un processo, il padre può determinare la causa della
terminazione esaminando il codice di stato riportato delle funzioni
-\texttt{wait} e \texttt{waitpid} in cui è riportato anche se la causa è un
+\func{wait} e \func{waitpid} in cui è riportato anche se la causa è un
segnale e nel caso quale; questo è il modo in cui la shell determina i motivi
della terminazione di un programma e scrive un eventuale messaggio di errore.
\textit{core dump} che registra lo stato del processo prima della terminazione
e può essere esaminato da un debugger per investigare sulla causa dell'errore.
Lo stesso avviene se i suddetti segnale vengono generati artificialmente con
-una \texttt{kill}.
+una \func{kill}.
tramite una macro di preprocessore, al suddetto numero. Sono questi nomi, che
sono standardizzati e uniformi rispetto alle varie implementazioni, che si
devono usare nei programmi. Tutti i nomi e le funzioni che concernono i
-segnali sono definiti nell'header di sistema \texttt{signal.h}.
+segnali sono definiti nell'header di sistema \file{signal.h}.
Il numero totale di segnali presenti è dato dalla macro \macro{NSIG}, e dato
che i numeri dei segnali sono allocati progressivamente, essa corrisponde
operazione del timer, e corrisponde dunque al numero di tick al secondo. Lo
standard POSIX definisce allo stesso modo la costante \macro{CLK\_TCK});
questo valore può comunque essere ottenuto con \func{sysconf} (vedi
- \secref{sec:intro_limits}).
+ \secref{sec:sys_limits}).
\end{itemize}
In genere si usa il \textit{calendar time} per tenere le date dei file e le
attualmente in esecuzione.
Una seconda funzione usata per riportare i codici di errore in maniera
-automatizzata sullo standard error (vedi \secref{sec:file_stdfiles}) è
+automatizzata sullo standard error (vedi \secref{sec:file_std_descr}) è
\func{perror}, il cui prototipo è:
\begin{prototype}{stdio.h}{void perror (const char *message)}
La funzione stampa il messaggio di errore relativo al valore corrente di
projects / gapil.git / commitdiff