essere in grado di fare qualunque operazione; per l'utente \textit{root}
infatti i meccanismi di controllo descritti in precedenza sono
disattivati.\footnote{i controlli infatti vengono sempre eseguiti da un codice
- del tipo \code{if (uid) \{ ... \}}}
+ del tipo: ``\code{if (uid) \{ \textellipsis\ \}}''.}
\section{Gli standard}
Uno dei problemi di portabilità del codice più comune è quello dei tipi di
dati utilizzati nei programmi, che spesso variano da sistema a sistema, o
-anche da una architettura ad un altra (ad esempio passando da macchine con
+anche da una architettura ad un'altra (ad esempio passando da macchine con
processori 32 bit a 64). In particolare questo è vero nell'uso dei cosiddetti
\textit{tipi elementari}\index{tipo!elementare} del linguaggio C (come
\ctyp{int}) la cui dimensione varia a seconda dell'architettura hardware.
\textbf{Tipo} & \textbf{Contenuto} \\
\hline
\hline
- \type{caddr\_t} & core address.\\
- \type{clock\_t} & contatore del tempo di sistema.\\
+ \type{caddr\_t} & Core address.\\
+ \type{clock\_t} & Contatore del tempo di sistema.\\
\type{dev\_t} & Numero di dispositivo.\\
\type{gid\_t} & Identificatore di un gruppo.\\
\type{ino\_t} & Numero di \textit{inode}\index{inode}.\\
Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di
libreria, e in seguito sono stati prodotti anche altri standard per la shell e
-i comandi di sistema (1003.2), per le estensioni realtime e per i thread
-(1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
+i comandi di sistema (1003.2), per le estensioni \textit{real-time} e per i
+thread (1003.1d e 1003.1c) e vari altri. In tab.~\ref{tab:intro_posix_std} è
riportata una classificazione sommaria dei principali documenti prodotti, e di
come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto
spesso si usa l'estensione IEEE anche come aggiunta al nome POSIX (ad esempio
alle stesse.
Nel 1997 fu annunciata la seconda versione delle \textit{Single UNIX
- Specification}, nota con la sigla SUSv2, in queste versione le interfacce
+ Specification}, nota con la sigla SUSv2, in questa versione le interfacce
specificate salgono a 1434 (e 3030 se si considerano le stazioni di lavoro
grafiche, per le quali sono inserite pure le interfacce usate da CDE che
richiede sia X11 che Motif). La conformità a questa versione permette l'uso
definendo opportune costanti prima dell'inclusione dei file degli header.
Se si vuole che i programmi seguano una stretta attinenza allo standard ANSI C
-si può usare l'opzione \cmd{-ansi} del compilatore, e non sarà riconosciuta
-nessuna funzione non riconosciuta dalle specifiche standard ISO per il C.
+si può usare l'opzione \cmd{-ansi} del compilatore, e non potrà essere
+utilizzata nessuna funzione non riconosciuta dalle specifiche standard ISO per
+il C.
Per attivare le varie opzioni è possibile definire le macro di preprocessore,
che controllano le funzionalità che le \acr{glibc} possono mettere a
Il sistema fa partire qualunque programma chiamando la funzione \func{main};
sta al programmatore chiamare così la funzione principale del programma da cui
si suppone iniziare l'esecuzione; in ogni caso senza questa funzione lo stesso
-\textit{linker} (ci chiama così il programma che effettua i collegamenti di
+\textit{linker} (si chiama così il programma che effettua i collegamenti di
cui sopra) darebbe luogo ad errori. Lo standard ISO C specifica che la
funzione \func{main} può non avere argomenti o prendere due argomenti che
rappresentano gli argomenti passati da linea di comando, in sostanza un
prototipo che va sempre bene è il seguente:
\includecodesnip{listati/main_def.c}
-In realtà nei sistemi Unix esiste un'altro modo per definire la funzione
+In realtà nei sistemi Unix esiste un altro modo per definire la funzione
\func{main}, che prevede la presenza di un terzo argomento, \code{char
*envp[]}, che fornisce (vedi sez.~\ref{sec:proc_environ})
l'\textsl{ambiente} del programma; questa forma però non è prevista dallo
tollerante nei confronti di piccoli errori come quello di chiamate doppie a
\func{free}. In particolare:
\begin{itemize}
-\item se la variabile è posta a zero gli errori vengono ignorati.
+\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 sez.~\ref{sec:file_std_stream}).
+ (vedi sez.~\ref{sec:file_std_stream});
\item se è posta a 2 viene chiamata \func{abort}, che in genere causa
l'immediata conclusione del programma.
\end{itemize}
Per limitare l'impatto di questi problemi, e semplificare la ricerca di
eventuali errori, l'implementazione delle routine di allocazione delle
\acr{glibc} mette a disposizione una serie di funzionalità che permettono di
-tracciare le allocazioni e le disallocazione, e definisce anche una serie di
+tracciare le allocazioni e le disallocazioni, e definisce anche una serie di
possibili \textit{hook} (\textsl{ganci}) che permettono di sostituire alle
funzioni di libreria una propria versione (che può essere più o meno
specializzata per il debugging). Esistono varie librerie che forniscono dei
cui torneremo in sez.~\ref{sec:proc_auto_var}.
-Queste due funzioni vengono utilizzate soltanto quando è necessario effettuare
-direttamente la gestione della memoria associata allo spazio dati di un
-processo, ad esempio qualora si debba implementare la propria versione delle
-routine di allocazione della memoria viste in sez.~\ref{sec:proc_mem_malloc}.
-La prima funzione è \funcd{brk}, ed il suo prototipo è:
+Le due funzioni seguenti vengono utilizzate soltanto quando è necessario
+effettuare direttamente la gestione della memoria associata allo spazio dati
+di un processo, ad esempio qualora si debba implementare la propria versione
+delle routine di allocazione della memoria viste in
+sez.~\ref{sec:proc_mem_malloc}. La prima funzione è \funcd{brk}, ed il suo
+prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
Il \textit{memory lock} persiste fintanto che il processo che detiene la
memoria bloccata non la sblocca. Chiaramente la terminazione del processo
comporta anche la fine dell'uso della sua memoria virtuale, e quindi anche di
-tutti i suoi \textit{memory lock}. Infine \textit{memory lock} non sono
+tutti i suoi \textit{memory lock}. Infine i \textit{memory lock} non sono
ereditati dai processi figli.\footnote{ma siccome Linux usa il \textit{copy on
write} (vedi sez.~\ref{sec:proc_fork}) gli indirizzi virtuali del figlio
sono mantenuti sullo stesso segmento di RAM del padre, quindi fintanto che
\subsection{Il formato degli argomenti}
\label{sec:proc_par_format}
-In genere passaggio degli argomenti al programma viene effettuato dalla shell,
-che si incarica di leggere la linea di comando e di effettuarne la scansione
-(il cosiddetto \textit{parsing}) per individuare le parole che la compongono,
-ciascuna delle quali viene considerata un argomento. Di norma per individuare
-le parole viene usato come carattere di separazione lo spazio o il tabulatore,
-ma il comportamento è modificabile attraverso l'impostazione della variabile
-di ambiente \cmd{IFS}.
+In genere il passaggio degli argomenti al programma viene effettuato dalla
+shell, che si incarica di leggere la linea di comando e di effettuarne la
+scansione (il cosiddetto \textit{parsing}) per individuare le parole che la
+compongono, ciascuna delle quali viene considerata un argomento. Di norma per
+individuare le parole viene usato come carattere di separazione lo spazio o il
+tabulatore, ma il comportamento è modificabile attraverso l'impostazione della
+variabile di ambiente \cmd{IFS}.
\begin{figure}[htb]
\centering
funzione all'interno di un ciclo, fintanto che essa non ritorna il valore -1
che indica che non ci sono più opzioni. Nel caso si incontri un'opzione non
dichiarata in \param{optstring} viene ritornato il carattere \texttt{'?'}
-mentre se un opzione che lo richiede non è seguita da un parametro viene
+mentre se un'opzione che lo richiede non è seguita da un parametro viene
ritornato il carattere \texttt{':'}, infine se viene incontrato il valore
\texttt{'-{}-'} la scansione viene considerata conclusa, anche se vi sono altri
elementi di \param{argv} che cominciano con il carattere \texttt{'-'}.
\subsection{Opzioni in formato esteso}
\label{sec:proc_opt_extended}
-Un'estensione di questo schema è costituito dalle cosiddette
+Un'estensione di questo schema è costituita dalle cosiddette
\textit{long-options} espresse nella forma \cmd{-{}-option=parameter}, anche
la gestione di queste ultime è stata standardizzata attraverso l'uso di una
versione estesa di \func{getopt}.
Gli standard POSIX e XPG3 definiscono alcune di queste variabili (le più
comuni), come riportato in tab.~\ref{tab:proc_env_var}. GNU/Linux le supporta
tutte e ne definisce anche altre: per una lista più completa si può
-controllare \cmd{man environ}.
+controllare \cmd{man 5 environ}.
\begin{table}[htb]
\centering
variabile esista già, sovrascrivendola se diverso da zero, lasciandola
immutata se uguale a zero.
-La seconda funzione prende come argomento una stringa analoga quella
+La seconda funzione prende come argomento una stringa analoga a quella
restituita da \func{getenv}, e sempre nella forma \code{NOME=valore}. Se la
variabile specificata non esiste la stringa sarà aggiunta all'ambiente, se
invece esiste il suo valore sarà impostato a quello specificato da
sua sintassi la possibilità di definire delle \textit{variadic
function}\index{variadic} che abbiano un numero variabile di argomenti,
attraverso l'uso nella dichiarazione della funzione dello speciale costrutto
-``\texttt{...}'', che viene chiamato \textit{ellipsis}.
+``\texttt{\textellipsis}'', che viene chiamato \textit{ellipsis}.
Lo standard però non provvede a livello di linguaggio alcun meccanismo con cui
dette funzioni possono accedere ai loro argomenti. L'accesso viene pertanto
\item Dichiarare la conclusione dell'estrazione degli argomenti invocando la
macro \macro{va\_end}.
\end{enumerate}
-in generale è perfettamente legittimo richiedere meno argomenti di quelli che
+In generale è perfettamente legittimo richiedere meno argomenti di quelli che
potrebbero essere stati effettivamente forniti, e nella esecuzione delle
\macro{va\_arg} ci si può fermare in qualunque momento ed i restanti argomenti
saranno ignorati; se invece si richiedono più argomenti di quelli forniti si
espressione di controllo di un comando condizionale, di selezione o di
iterazione;
\item come operando per l'operatore di negazione (\code{!}) in una espressione
- di controllo di un comando condizionale, di selezione o di iterazione.
+ di controllo di un comando condizionale, di selezione o di iterazione;
\item come espressione a sé stante.
\end{itemize}
In generale, dato che l'unica differenza fra la chiamata diretta e quella
-ottenuta da un \func{longjmp}, è il valore di ritorno di \func{setjmp}, essa è
-usualmente chiamata all'interno di un comando \code{if}.
+ottenuta da un \func{longjmp} è costituita dal valore di ritorno di
+\func{setjmp}, essa è usualmente chiamata all'interno di un comando \code{if}.
Uno dei punti critici dei salti non-locali è quello del valore delle
variabili, ed in particolare quello delle variabili automatiche della funzione
\begin{itemize*}
\item i file aperti e gli eventuali flag di
\textit{close-on-exec}\index{\textit{close-on-exec}} impostati (vedi
- sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl}).
+ sez.~\ref{sec:proc_exec} e sez.~\ref{sec:file_fcntl});
\item gli identificatori per il controllo di accesso: l'\textsl{user-ID
reale}, il \textsl{group-ID reale}, l'\textsl{user-ID effettivo}, il
\textsl{group-ID effettivo} ed i \textit{group-ID supplementari} (vedi
- sez.~\ref{sec:proc_access_id}).
+ sez.~\ref{sec:proc_access_id});
\item gli identificatori per il controllo di sessione: il \textit{process
group-ID} e il \textit{session id} ed il terminale di controllo (vedi
- sez.~\ref{sec:sess_proc_group}).
+ sez.~\ref{sec:sess_proc_group});
\item la directory di lavoro e la directory radice (vedi
- sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot}).
-\item la maschera dei permessi di creazione (vedi sez.~\ref{sec:file_umask}).
+ sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
+\item la maschera dei permessi di creazione (vedi sez.~\ref{sec:file_umask});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
- azioni installate (vedi sez.~\ref{sec:sig_gen_beha}).
+ azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
- sez.~\ref{sec:ipc_sysv_shm}).
-\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit}).
+ sez.~\ref{sec:ipc_sysv_shm});
+\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
\item le variabili di ambiente (vedi sez.~\ref{sec:proc_environ}).
\end{itemize*}
-le differenze fra padre e figlio dopo la \func{fork} invece sono:
+Le differenze fra padre e figlio dopo la \func{fork} invece sono:
\begin{itemize*}
-\item il valore di ritorno di \func{fork}.
-\item il \acr{pid} (\textit{process id}).
+\item il valore di ritorno di \func{fork};
+\item il \acr{pid} (\textit{process id});
\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene
- impostato al \acr{pid} del padre.
+ impostato al \acr{pid} del padre;
\item i valori dei tempi di esecuzione della struttura \struct{tms} (vedi
- sez.~\ref{sec:sys_cpu_times}) che nel figlio sono posti a zero.
+ sez.~\ref{sec:sys_cpu_times}) che nel figlio sono posti a zero;
\item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}), che non
- vengono ereditati dal figlio.
+ vengono ereditati dal figlio;
\item gli allarmi ed i segnali pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che
per il figlio vengono cancellati.
\end{itemize*}
Dato che Linux supporta il \textit{copy on
write}\index{\textit{copy~on~write}} la perdita di prestazioni è
assolutamente trascurabile, e l'uso di questa funzione (che resta un caso
-speciale della system call \func{\_\_clone}), è deprecato; per questo
-eviteremo di trattarla ulteriormente.
+speciale della system call \func{\_\_clone}) è deprecato; per questo eviteremo
+di trattarla ulteriormente.
-\subsection{La conclusione di un processo.}
+\subsection{La conclusione di un processo}
\label{sec:proc_termination}
In sez.~\ref{sec:proc_conclusion} abbiamo già affrontato le modalità con cui
memoria che stava usando, e così via; l'elenco completo delle operazioni
eseguite alla chiusura di un processo è il seguente:
\begin{itemize*}
-\item tutti i file descriptor sono chiusi.
-\item viene memorizzato lo stato di terminazione del processo.
+\item tutti i file descriptor sono chiusi;
+\item viene memorizzato lo stato di terminazione del processo;
\item ad ogni processo figlio viene assegnato un nuovo padre (in genere
- \cmd{init}).
+ \cmd{init});
\item viene inviato il segnale \const{SIGCHLD} al processo padre (vedi
- sez.~\ref{sec:sig_sigchld}).
+ sez.~\ref{sec:sig_sigchld});
\item se il processo è un leader di sessione ed il suo terminale di controllo
è quello della sessione viene mandato un segnale di \const{SIGHUP} a tutti i
processi del gruppo di foreground e il terminale di controllo viene
- disconnesso (vedi sez.~\ref{sec:sess_ctrl_term}).
+ disconnesso (vedi sez.~\ref{sec:sess_ctrl_term});
\item se la conclusione di un processo rende orfano un \textit{process
group} ciascun membro del gruppo viene bloccato, e poi gli vengono
inviati in successione i segnali \const{SIGHUP} e \const{SIGCONT}
\hline
\hline
\macro{WIFEXITED(s)} & Condizione vera (valore non nullo) per un processo
- figlio che sia terminato normalmente. \\
+ figlio che sia terminato normalmente. \\
\macro{WEXITSTATUS(s)} & Restituisce gli otto bit meno significativi dello
- stato di uscita del processo (passato attraverso \func{\_exit}, \func{exit}
- o come valore di ritorno di \func{main}). Può essere valutata solo se
- \val{WIFEXITED} ha restituito un valore non nullo.\\
+ stato di uscita del processo (passato attraverso
+ \func{\_exit}, \func{exit} o come valore di
+ ritorno di \func{main}). Può essere valutata solo
+ se \val{WIFEXITED} ha restituito un valore non
+ nullo.\\
\macro{WIFSIGNALED(s)} & Vera se il processo figlio è terminato
- in maniera anomala a causa di un segnale che non è stato catturato (vedi
- sez.~\ref{sec:sig_notification}).\\
- \macro{WTERMSIG(s)} & restituisce il numero del segnale che ha causato
- la terminazione anomala del processo. Può essere valutata solo se
- \val{WIFSIGNALED} ha restituito un valore non nullo.\\
+ in maniera anomala a causa di un segnale che non
+ è stato catturato (vedi
+ sez.~\ref{sec:sig_notification}).\\
+ \macro{WTERMSIG(s)} & Restituisce il numero del segnale che ha causato
+ la terminazione anomala del processo. Può essere
+ valutata solo se \val{WIFSIGNALED} ha restituito
+ un valore non nullo.\\
\macro{WCOREDUMP(s)} & Vera se il processo terminato ha generato un
- file si \textit{core dump}. Può essere valutata solo se
- \val{WIFSIGNALED} ha restituito un valore non nullo.\footnotemark \\
+ file di \textit{core dump}. Può essere valutata
+ solo se \val{WIFSIGNALED} ha restituito un valore
+ non nullo.\footnotemark \\
\macro{WIFSTOPPED(s)} & Vera se il processo che ha causato il ritorno di
- \func{waitpid} è bloccato. L'uso è possibile solo avendo specificato
- l'opzione \const{WUNTRACED}. \\
- \macro{WSTOPSIG(s)} & restituisce il numero del segnale che ha bloccato
- il processo, Può essere valutata solo se \val{WIFSTOPPED} ha
- restituito un valore non nullo. \\
+ \func{waitpid} è bloccato. L'uso è possibile solo
+ avendo specificato l'opzione \const{WUNTRACED}. \\
+ \macro{WSTOPSIG(s)} & Restituisce il numero del segnale che ha bloccato
+ il processo. Può essere valutata solo se
+ \val{WIFSTOPPED} ha restituito un valore non
+ nullo. \\
\hline
\end{tabular}
\caption{Descrizione delle varie macro di preprocessore utilizzabili per
\headdecl{sys/times.h} \headdecl{sys/types.h} \headdecl{sys/wait.h}
\headdecl{sys/resource.h}
- \funcdecl{pid\_t wait4(pid\_t pid, int * status, int options, struct rusage
- * rusage)}
+ \funcdecl{pid\_t wait4(pid\_t pid, int *status, int options, struct rusage
+ *rusage)}
È identica a \func{waitpid} sia per comportamento che per i valori degli
argomenti, ma restituisce in \param{rusage} un sommario delle risorse usate
dal processo.
riconosciuto come tale, o compilato per un'altra architettura.
\item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
- \item[\errcode{ETXTBSY}] L'eseguibile è aperto in scrittura da uno o più
+ \item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
processi.
- \item[\errcode{EINVAL}] L'eseguibile ELF ha più di un segmento
+ \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
\const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
interprete.
- \item[\errcode{ELIBBAD}] Un interprete ELF non è in un formato
+ \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
riconoscibile.
- \item[\errcode{E2BIG}] La lista degli argomenti è troppo grande.
+ \item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
ed inoltre anche \errval{EFAULT}, \errval{ENOMEM}, \errval{EIO},
\errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR}, \errval{ENFILE},
quando la sua funzione \func{main} è dichiarata nella forma
\code{main(int argc, char *argv[], char *envp[])}.
-Le altre funzioni della famiglia servono per fornire all'utente una serie
-possibile di diverse interfacce per la creazione di un nuovo processo. I loro
+Le altre funzioni della famiglia servono per fornire all'utente una serie di
+possibili diverse interfacce per la creazione di un nuovo processo. I loro
prototipi sono:
\begin{functions}
\headdecl{unistd.h}
argomenti a lista &$\bullet$&$\bullet$&$\bullet$&&& \\
argomenti a vettore &&&&$\bullet$&$\bullet$&$\bullet$\\
\hline
- filename completo &&$\bullet$&&&$\bullet$& \\
- ricerca su \var{PATH}&$\bullet$&&$\bullet$&$\bullet$&&$\bullet$ \\
+ filename completo &$\bullet$&&$\bullet$&$\bullet$&&$\bullet$\\
+ ricerca su \var{PATH} &&$\bullet$&&&$\bullet$& \\
\hline
ambiente a vettore &&&$\bullet$&&&$\bullet$ \\
uso di \var{environ} &$\bullet$&$\bullet$&&$\bullet$&$\bullet$& \\
la lista completa è la seguente:
\begin{itemize*}
\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id}
- (\acr{ppid}).
+ (\acr{ppid});
\item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i
- \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id}).
+ \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id});
\item il \textit{session id} (\acr{sid}) ed il \textit{process group-ID}
- (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group}.
-\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term}).
-\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort}).
+ (\acr{pgid}), vedi sez.~\ref{sec:sess_proc_group};
+\item il terminale di controllo (vedi sez.~\ref{sec:sess_ctrl_term});
+\item il tempo restante ad un allarme (vedi sez.~\ref{sec:sig_alarm_abort});
\item la directory radice e la directory di lavoro corrente (vedi
- sez.~\ref{sec:file_work_dir}).
+ sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file (\var{umask}, vedi
sez.~\ref{sec:file_umask}) ed i \textit{lock} sui file (vedi
- sez.~\ref{sec:file_locking}).
+ sez.~\ref{sec:file_locking});
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
- sez.~\ref{sec:sig_sigmask}).
-\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit}).
+ sez.~\ref{sec:sig_sigmask});
+\item i limiti sulle risorse (vedi sez.~\ref{sec:sys_resource_limit});
\item i valori delle variabili \var{tms\_utime}, \var{tms\_stime},
\var{tms\_cutime}, \var{tms\_ustime} (vedi sez.~\ref{sec:sys_cpu_times}).
\end{itemize*}
gruppo cui il file appartiene (per i dettagli vedi sez.~\ref{sec:proc_perms}).
Se il file da eseguire è in formato \emph{a.out} e necessita di librerie
-condivise, viene lanciato il \textit{linker} dinamico \cmd{ld.so} prima del
-programma per caricare le librerie necessarie ed effettuare il link
+condivise, viene lanciato il \textit{linker} dinamico \cmd{/lib/ld.so} prima
+del programma per caricare le librerie necessarie ed effettuare il link
dell'eseguibile. Se il programma è in formato ELF per caricare le librerie
dinamiche viene usato l'interprete indicato nel segmento \const{PT\_INTERP},
in genere questo è \file{/lib/ld-linux.so.1} per programmi linkati con le
\acr{libc5}, e \file{/lib/ld-linux.so.2} per programmi linkati con le
-\acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con
-una linea nella forma \cmd{\#!/path/to/interpreter} dove l'interprete indicato
-deve esse un programma valido (binario, non un altro script) che verrà
-chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti]
- filename}.
+\acr{glibc}. Infine nel caso il file sia uno script esso deve iniziare con una
+linea nella forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete
+indicato deve essere un programma valido (binario, non un altro script) che
+verrà chiamato come se si fosse eseguito il comando \cmd{interpreter
+ [argomenti] filename}.
Con la famiglia delle \func{exec} si chiude il novero delle funzioni su cui è
basata la gestione dei processi in Unix: con \func{fork} si crea un nuovo
Lo standard POSIX.1b prevede comunque che i due valori della massima e minima
priorità statica possano essere ottenuti, per ciascuna delle politiche di
-scheduling realtime, tramite le due funzioni \funcd{sched\_get\_priority\_max}
-e \funcd{sched\_get\_priority\_min}, i cui prototipi sono:
+scheduling \textit{real-time}, tramite le due funzioni
+\funcd{sched\_get\_priority\_max} e \funcd{sched\_get\_priority\_min}, i cui
+prototipi sono:
\begin{functions}
\headdecl{sched.h}
projects / gapil.git / commitdiff