solo per le fifo, torneremo questo in \secref{sec:ipc_named_pipe}). \\
\macro{O\_NOCTTY} & se \var{pathname} si riferisce ad un device di
terminale, questo non diventerà il terminale di controllo, anche se il
- processo non ne ha ancora uno (si veda \secref{sec:sess_xxx}). \\
+ processo non ne ha ancora uno (si veda \secref{sec:sess_ctrl_term}). \\
\macro{O\_SHLOCK} & opzione di BSD, acquisisce uno shared lock (vedi
\secref{sec:file_locking}) sul file. Non è disponibile in Linux. \\
\macro{O\_EXLOCK} & opzione di BSD, acquisisce uno lock esclusivo (vedi
\hline
\hline
$<-1$& -- & attende per un figlio il cui \textit{process group} (vedi
- \ref{sec:sess_proc_group}) è uguale al
+ \secref{sec:sess_proc_group}) è uguale al
valore assoluto di \var{pid}. \\
$-1$ & \macro{WAIT\_ANY} & attende per un figlio qualsiasi, usata in
questa maniera è equivalente a \func{wait}.\\
supplementari} (vedi \secref{sec:proc_access_id}).
\item il \textit{session id} (\acr{sid}) ed il \textit{process groupid}
(\acr{pgid}), vedi \secref{sec:sess_proc_group}.
-\item il terminale di controllo (vedi \secref{sec:sess_xxx}).
+\item il terminale di controllo (vedi \secref{sec:sess_ctrl_term}).
\item il tempo restante ad un allarme (vedi \secref{sec:sig_alarm_abort}).
\item la directory radice e la directory di lavoro corrente (vedi
\secref{sec:file_work_dir}).
\textit{process group} di cui esso diventa leader (come per i \textit{process
group} un processo si dice leader di sessione\footnote{in Linux la proprietà
è mantenuta in maniera indipendente con un apposito campo \var{leader} in
- \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}).
-Infine la funzione distacca il processo da ogni terminale di controllo
-(torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse in
-precedenza associato.
+ \var{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed unico
+componente. Inoltre la funzione distacca il processo da ogni terminale di
+controllo (torneremo sull'argomento in \secref{sec:sess_ctrl_term}) cui fosse
+in precedenza associato.
La funzione ha successo soltanto se il processo non è già leader di un
\textit{process group}, per cui per usarla di norma si esegue una \func{fork}
-\subsection{Il terminale di controllo}
+\subsection{Il terminale di controllo e il controllo di sessione}
\label{sec:sess_ctrl_term}
Come accennato in \secref{sec:sess_job_control_overview}, nel sistema del
dal quale ricevono gli eventuali segnali da tastiera.
A tale scopo lo standard POSIX.1 prevede che ad ogni sessione possa essere
-associato un terminale di controllo (e non più di uno); in Linux questo viene
-realizzato mantenendo fra gli attributi di ciascun processo anche il terminale
+associato un terminale di controllo; in Linux questo viene realizzato
+mantenendo fra gli attributi di ciascun processo anche qual'è il suo terminale
di controllo. \footnote{Lo standard POSIX.1 non specifica nulla riguardo
l'implementazione; in Linux anch'esso viene mantenuto nella solita struttura
- \var{task\_struct}, nel campo \var{tty}.}
-In generale ogni processo eredita dal padre, insieme al \acr{pgid} e al
-\acr{sid} anche il terminale di controllo. In questo modo tutti processi
-originati dallo stesso leader di sessione mantengono lo stesso terminale di
-controllo.
+ \var{task\_struct}, nel campo \var{tty}.} In generale ogni processo eredita
+dal padre, insieme al \acr{pgid} e al \acr{sid} anche il terminale di
+controllo. In questo modo tutti processi originati dallo stesso leader di
+sessione mantengono lo stesso terminale di controllo.
Alla creazione di una nuova sessione con \func{setsid} ogni associazione con
il precedente terminale di controllo viene cancellata, ed il processo che è
divenuto un nuovo leader di sessione dovrà riottenere (qualora sia necessario,
-cosa che come vedremo in \secref{sec:sess_daemon} non è sempre vera), un
+cosa che, come vedremo in \secref{sec:sess_daemon}, non è sempre vera), un
terminale di controllo. In generale questo viene fatto automaticamente dal
sistema quando il leader di sessione apre il suo primo terminale\footnote{a
meno di non avere richiesto esplicitamente che questo non diventi un
\secref{sec:file_open}). In questo Linux segue la semantica di SVr4; BSD
invece richiede che il terminale venga allocato esplicitamente con una
\func{ioctl} con il comando \macro{TIOCSCTTY}.} che diventa automaticamente
-il terminale di controllo.
+il terminale di controllo.
+Per ciascuna sessione di lavoro avremo allora un terminale di controllo, ed un
+processo di \textit{foreground}, che è quello
+Il kernel identifica
\subsection{Dal login alla shell}
\label{sec:sess_login}
\hline
\macro{\_POSIX\_JOB\_CONTROL}& il sistema supporta il
\textit{job control} (vedi
- \secref{sec:sess_xxx}).\\
+ \secref{sec:sess_job_control}).\\
\macro{\_POSIX\_SAVED\_IDS} & il sistema supporta gli identificatori del
gruppo \textit{saved} (vedi
\secref{sec:proc_access_id})
\textit{process time} (vedi \secref{sec:sys_unix_time}).\\
\texttt{\_SC\_JOB\_CONTROL}&\macro{\_POSIX\_JOB\_CONTROL}&
Indica se è supportato il \textit{job control} (vedi
- \secref{sec:sess_xxx}) in stile POSIX.\\
+ \secref{sec:sess_job_control}) in stile POSIX.\\
\texttt{\_SC\_SAVED\_IDS}&\macro{\_POSIX\_SAVED\_IDS}&
Indica se il sistema supporta i \textit{saved id} (vedi
\secref{sec:proc_access_id}).\\