\item i \textit{lock} sui file (vedi sez.~\ref{sec:file_locking}) e sulla
memoria (vedi sez.~\ref{sec:proc_mem_lock}), che non vengono ereditati dal
figlio;
-\item gli allarmi (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali pendenti
- (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono cancellati.
+\item gli allarmi, i timer (vedi sez.~\ref{sec:sig_alarm_abort}) ed i segnali
+ pendenti (vedi sez.~\ref{sec:sig_gen_beha}), che per il figlio vengono
+ cancellati.
\item le operazioni di I/O asincrono in corso (vedi
sez.~\ref{sec:file_asyncronous_io}) che non vengono ereditate dal figlio;
\item gli aggiustamenti fatti dal padre ai semafori con \func{semop} (vedi
sez.~\ref{sec:sig_notification}), che non vengono ereditate dal figlio;
\item le mappature di memoria marcate come \const{MADV\_DONTFORK} (vedi
sez.~\ref{sec:file_memory_map}) che non vengono ereditate dal figlio;
-\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:prctl_xxx}) che
+\item l'impostazione con \func{prctl} (vedi sez.~\ref{sec:process_prctl}) che
notifica al figlio la terminazione del padre viene cancellata;
\item il segnale di terminazione del figlio è sempre \const{SIGCHLD} anche
qualora nel padre fosse stato modificato (vedi sez.~\ref{sec:process_clone}).
realtà viene notificato soltanto il caso in cui il processo è stato fermato
da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in
cui lo stato \textit{stopped} è dovuto all'uso di \func{ptrace} (vedi
- sez.~\ref{sec:xxx_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}), mentre
-con \const{WCONTINUED} la funzione ritorna quando un processo in stato
+ sez.~\ref{sec:process_ptrace}).} (vedi tab.~\ref{tab:proc_proc_states}),
+mentre con \const{WCONTINUED} la funzione ritorna quando un processo in stato
\textit{stopped} riprende l'esecuzione per la ricezione del segnale
\const{SIGCONT} (l'uso di questi segnali per il controllo di sessione è
-dettagliato in sez.~\ref{sec:sess_ctrl_term}).
+dettagliato in sez.~\ref{sec:sess_ctrl_term}).
La terminazione di un processo figlio (così come gli altri eventi osservabili
con \func{waitpid}) è chiaramente un evento asincrono rispetto all'esecuzione
sez.~\ref{sec:thread_xxx}) sono cancellati e tutti gli oggetti ad essi
relativi (vedi sez.~\ref{sec:thread_xxx}) rimossi;
\item viene impostato il flag \const{PR\_SET\_DUMPABLE} di \func{prctl} (vedi
- sez.~\ref{sec:prctl_xxx}) a meno che il programma da eseguire non sia
+ sez.~\ref{sec:process_prctl}) a meno che il programma da eseguire non sia
\itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} (vedi
sez.~\ref{sec:proc_access_id});
\item il flag \const{PR\_SET\_KEEPCAPS} di \func{prctl} (vedi
- sez.~\ref{sec:prctl_xxx}) viene cancellato;
+ sez.~\ref{sec:process_prctl}) viene cancellato;
\item il nome del processo viene impostato al nome del file contenente il
programma messo in esecuzione;
\item il segnale di terminazione viene reimpostato a \const{SIGCHLD};
altri processi occorrono privilegi amministrativi, ed in particolare la
capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).}
cioè quelli il cui user-ID reale corrisponde all'user-ID reale o effettivo del
-chiamante. Data la possibilità di ottenere un blocco totale dello stesso, solo
+chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo
l'amministratore\footnote{o un processo con la capacità
\const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può
impostare un processo ad una priorità di I/O nella classe
-\const{IOPRIO\_CLASS\_RT} o \const{IOPRIO\_CLASS\_IDLE}.
+\const{IOPRIO\_CLASS\_RT}, lo stesso privilegio era richiesto anche per la
+classe \const{IOPRIO\_CLASS\_IDLE} fino al kernel 2.6.24, ma dato che in
+questo caso non ci sono effetti sugli altri processi questo limite è stato
+rimosso a partire dal kernel 2.6.25.
%TODO verificare http://lwn.net/Articles/355987/
% vedi man numa e le pagine di manuale relative
% vedere anche dove metterle...
+
+\section{Funzioni di gestione avanzata}
+\label{sec:proc_advanced_control}
+
+Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
+attengono alla gestione ordinaria dei processi e delle loro proprietà più
+comuni. Tratteremo qui alcune \textit{system call} specialistiche dedicate
+alla gestione di alcune funzionalità specifiche ed avanzate il cui uso è in
+genere piuttosto ridotto.
+
+\subsection{La system call \func{clone}}
+\label{sec:process_clone}
+
+Da fare
+
+\subsection{La funzione \func{prctl}}
+\label{sec:process_prctl}
+
+Da fare
+
+\subsection{La funzione \func{ptrace}}
+\label{sec:process_ptrace}
+
+Da fare
+
+\subsection{L'accesso alle porte di I/O}
+\label{sec:process_io_port}
+
+%
+% TODO l'I/O sulle porte di I/O
+% consultare le manpage di ioperm, iopl e outb
+
+Da fare
+
\section{Problematiche di programmazione multitasking}
\label{sec:proc_multi_prog}
opportunamente protette da meccanismi di sincronizzazione (torneremo su queste
problematiche di questo tipo in cap.~\ref{cha:IPC}).
-\itindbeg{deadlock}
-Un caso particolare di \textit{race condition} sono poi i cosiddetti
-\textit{deadlock}, particolarmente gravi in quanto comportano spesso il blocco
-completo di un servizio, e non il fallimento di una singola operazione. Per
-definizione un \textit{deadlock} è una situazione in cui due o più processi
-non sono più in grado di proseguire perché ciascuno aspetta il risultato di
-una operazione che dovrebbe essere eseguita dall'altro.
-
+\itindbeg{deadlock} Un caso particolare di \textit{race condition} sono poi i
+cosiddetti \textit{deadlock} (traducibile in \textsl{condizioni di stallo}),
+particolarmente gravi in quanto comportano spesso il blocco completo di un
+servizio, e non il fallimento di una singola operazione. Per definizione un
+\textit{deadlock} è una situazione in cui due o più processi non sono più in
+grado di proseguire perché ciascuno aspetta il risultato di una operazione che
+dovrebbe essere eseguita dall'altro.
L'esempio tipico di una situazione che può condurre ad un
\textit{deadlock} è quello in cui un flag di
projects / gapil.git / blobdiff