sono stati creati, questo viene chiamato in genere \acr{ppid} (da
\textit{parent process id}). Questi due identificativi possono essere
ottenuti da programma usando le funzioni:
-
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\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}}
attraverso l'uso di questa funzione, essa quindi riveste un ruolo centrale
tutte le volte che si devono scrivere programmi che usano il multitasking. Il
prototipo della funzione è:
-
\begin{functions}
\headdecl{sys/types.h}
\headdecl{unistd.h}
\textit{zombie} la tabella dei processi; le funzioni deputate a questo compito
sono sostanzialmente due, \func{wait} e \func{waitpid}. La prima, il cui
prototipo è:
-
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
ampie, legate anche al controllo di sessione. Dato che è possibile ottenere
lo stesso comportamento di \func{wait} si consiglia di utilizzare sempre
questa funzione; il suo prototipo è:
-
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\label{tab:proc_status_macro}
\end{table}
-
Entrambe le funzioni restituiscono lo stato di terminazione del processo
tramite il puntatore \var{status} (se non interessa memorizzare lo stato si
può passare un puntatore nullo). Il valore restituito da entrambe le funzioni
kernel può restituire al processo padre ulteriori informazioni sulle risorse
usate dal processo terminato e dai vari figli. Queste funzioni, che diventano
accessibili definendo la costante \macro{\_USE\_BSD}, sono:
-
\begin{functions}
\headdecl{sys/times.h}
\headdecl{sys/types.h}
famiglia di funzioni) che possono essere usate per questo compito, che in
realtà (come mostrato in \figref{fig:proc_exec_relat}), costituiscono un
front-end a \func{execve}. Il prototipo di quest'ultima è:
-
\begin{prototype}{unistd.h}
{int execve(const char * filename, char * const argv [], char * const 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
prototipi sono:
-
\begin{functions}
\headdecl{unistd.h}
\funcdecl{int execl(const char *path, const char *arg, ...)}
\begin{figure}[htb]
\centering
- \includegraphics[width=13cm]{img/exec_rel.eps}
+ \includegraphics[width=13cm]{img/exec_rel}
\caption{La interrelazione fra le sei funzioni della famiglia \func{exec}}
\label{fig:proc_exec_relat}
\end{figure}
\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.
tutti gli unix prevedono che i processi abbiano almeno due gruppi di
identificatori, chiamati rispettivamente \textit{real} ed \textit{effective}.
-
\begin{table}[htb]
\footnotesize
\centering
Come nel caso del \acr{pid} e del \acr{ppid} tutti questi identificatori
possono essere letti dal processo attraverso delle opportune funzioni, i cui
prototipi sono i seguenti:
-
\begin{functions}
-\headdecl{unistd.h}
-\headdecl{sys/types.h}
-\funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
-processo corrente.
-\funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
-processo corrente.
-\funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
-processo corrente.
-\funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
-processo corrente.
-
-Queste funzioni non riportano condizioni di errore.
+ \headdecl{unistd.h}
+ \headdecl{sys/types.h}
+
+ \funcdecl{uid\_t getuid(void)} restituisce il \textit{real user ID} del
+ processo corrente.
+
+ \funcdecl{uid\_t geteuid(void)} restituisce l'\textit{effective user ID} del
+ processo corrente.
+
+ \funcdecl{gid\_t getgid(void)} restituisce il \textit{real group ID} del
+ processo corrente.
+
+ \funcdecl{gid\_t getegid(void)} restituisce l'\textit{effective group ID} del
+ processo corrente.
+
+ Queste funzioni non riportano condizioni di errore.
\end{functions}
In generale l'uso di privilegi superiori deve essere limitato il più
\func{setgid}; come accennato in \secref{sec:proc_user_group} in Linux esse
seguono la semantica POSIX che prevede l'esistenza di \textit{saved user id} e
\textit{saved group id}; i loro prototipi sono:
-
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
alla versione 4.3+BSD TODO, verificare e aggiornare la nota} i \textit{saved
id} le usava per poter scambiare fra di loro effective e real id. I
prototipi sono:
-
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
Queste due funzioni sono una estensione introdotta in Linux dal kernel 2.1.44,
e permettono un completo controllo su tutti gli identificatori (\textit{real},
\textit{effective} e \textit{saved}), i prototipi sono:
-
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
Queste funzioni sono un'estensione allo standard POSIX.1 (ma sono comunque
supportate dalla maggior parte degli unix) e usate per cambiare gli
\textit{effective id}; i loro prototipi sono:
-
\begin{functions}
\headdecl{unistd.h}
\headdecl{sys/types.h}
Le due funzioni usate per cambiare questi identificatori sono \func{setfsuid}
e \func{setfsgid}, ovviamente sono specifiche di Linux e non devono essere
usate se si intendono scrivere programmi portabili; i loro prototipi sono:
-
\begin{functions}
\headdecl{sys/fsuid.h}
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
processi.
Nel caso dei segnali invece la situazione è molto più delicata, in quanto lo
-stesso processo può essere interrotto in qualunque momento, e le operazioni di
-un eventuale \textit{signal handler} saranno compiute nello stesso spazio di
-indirizzi. Per questo anche solo il solo accesso o l'assegnazione di una
-variabile possono non essere più operazioni atomiche (torneremo su questi
-aspetti in \secref{sec:sign_xxx}).
+stesso processo, e pure alcune system call, possono essere interrotti in
+qualunque momento, e le operazioni di un eventuale \textit{signal handler}
+sono compiute nello stesso spazio di indirizzi del processo. Per questo anche
+solo il solo accesso o l'assegnazione di una variabile possono non essere più
+operazioni atomiche (torneremo su questi aspetti in \secref{sec:sign_xxx}).
In questo caso il sistema provvede un tipo di dato, il \type{sig\_atomic\_t},
il cui accesso è assicurato essere atomico. In pratica comunque si può
Un caso particolare di \textit{race condition} sono poi i cosiddetti
\textit{deadlock}; l'esempio tipico è quello di un flag di ``occupazione'' che
viene rilasciato da un evento asincrono fra il controllo (in cui viene trovato
-occupato) e la successiva messa in attesa, attesa che a questo punto diventerà
+occupato) e la successiva messa in attesa, che a questo punto diventerà
perpetua (da cui il nome di \textit{deadlock}) in quanto l'evento di sblocco
-di questa è stato perso.
+del flag è stato perso fra il controllo e la messa in attesa.
\subsection{Le funzioni rientranti}
projects / gapil.git / blobdiff