%% session.tex
%%
-%% Copyright (C) 2000-2006 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
+
\chapter{Terminali e sessioni di lavoro}
\label{cha:session}
In generale allora all'interno di una sessione avremo un eventuale (può non
esserci) \itindex{process~group} \textit{process group} in
\textit{foreground}, che riunisce i processi che possono accedere al
-terminale, e più \textit{process group} in \textit{background}, che non
-possono accedervi. Il job control prevede che quando un processo appartenente
-ad un raggruppamento in \textit{background} cerca di accedere al terminale,
-venga inviato un segnale a tutti i processi del raggruppamento, in modo da
-bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
+terminale, e più \itindex{process~group} \textit{process group} in
+\textit{background}, che non possono accedervi. Il job control prevede che
+quando un processo appartenente ad un raggruppamento in \textit{background}
+cerca di accedere al terminale, venga inviato un segnale a tutti i processi
+del raggruppamento, in modo da bloccarli (vedi sez.~\ref{sec:sess_ctrl_term}).
Un comportamento analogo si ha anche per i segnali generati dai comandi di
tastiera inviati dal terminale che vengono inviati a tutti i processi del
processi dall'uno all'altro, ma sempre all'interno di una stessa sessione.
Ciascun raggruppamento di processi ha sempre un processo principale, il
-cosiddetto \itindex{process~group~leader}\textit{process group leader}, che è
+cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è
identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere
questo è il primo processo del raggruppamento, che si incarica di lanciare
tutti gli altri. Un nuovo raggruppamento si crea con la funzione
quest'ultimo, per sé stesso, in modo che il cambiamento di \textit{process
group} sia immediato per entrambi; una delle due chiamate sarà ridondante,
ma non potendo determinare quale dei due processi viene eseguito per primo,
-occorre eseguirle comunque entrambe per evitare di esporsi ad una \textit{race
- condition}\itindex{race~condition}.
+occorre eseguirle comunque entrambe per evitare di esporsi ad una
+\itindex{race~condition} \textit{race condition}.
Si noti come nessuna delle funzioni esaminate finora permetta di spostare un
processo da una sessione ad un altra; infatti l'unico modo di far cambiare
controllo. Consideriamo allora cosa avviene di norma nel \textit{job
control}: una sessione viene creata con \func{setsid} che crea anche un
nuovo \itindex{process~group} \textit{process group}: per definizione
-quest'ultimo è sempre \textsl{orfano}, dato che il padre del leader di
-sessione è fuori dalla stessa e il nuovo \textit{process group}
-\itindex{process~group} contiene solo il leader di sessione. Questo è un caso
-limite, e non viene emesso nessun segnale perché quanto previsto dallo
-standard riguarda solo i raggruppamenti che diventano orfani in seguito alla
-terminazione di un processo.\footnote{l'emissione dei segnali infatti avviene
- solo nella fase di uscita del processo, come una delle operazioni legate
- all'esecuzione di \func{\_exit}, secondo quanto illustrato in
- sez.~\ref{sec:proc_termination}.}
+quest'ultimo è sempre \itindex{process~group~orphaned} \textsl{orfano}, dato
+che il padre del leader di sessione è fuori dalla stessa e il nuovo
+\textit{process group} \itindex{process~group} contiene solo il leader di
+sessione. Questo è un caso limite, e non viene emesso nessun segnale perché
+quanto previsto dallo standard riguarda solo i raggruppamenti che diventano
+orfani in seguito alla terminazione di un processo.\footnote{l'emissione dei
+ segnali infatti avviene solo nella fase di uscita del processo, come una
+ delle operazioni legate all'esecuzione di \func{\_exit}, secondo quanto
+ illustrato in sez.~\ref{sec:proc_termination}.}
Il leader di sessione provvederà a creare nuovi raggruppamenti che a questo
punto non sono orfani in quanto esso resta padre per almeno uno dei processi
Il servizio prevede vari meccanismi di notifica, e, come ogni altro servizio
in un sistema unix-like, viene gestito attraverso un apposito programma,
\cmd{syslogd}, che è anch'esso un \textsl{demone}. In generale i messaggi di
-errore vengono raccolti dal file speciale \file{/dev/log}, un
-\textit{socket}\index{socket} locale (vedi sez.~\ref{sec:sock_sa_local})
-dedicato a questo scopo, o via rete, con un \textit{socket} UDP, o da un
-apposito demone, \cmd{klogd}, che estrae i messaggi del kernel.\footnote{i
- messaggi del kernel sono tenuti in un buffer circolare e scritti tramite la
- funzione \func{printk}, analoga alla \func{printf} usata in user space; una
- trattazione eccellente dell'argomento si trova in \cite{LinDevDri}, nel
- quarto capitolo.}
+errore vengono raccolti dal file speciale \file{/dev/log}, un socket locale
+(vedi sez.~\ref{sec:sock_sa_local}) dedicato a questo scopo, o via rete, con
+un socket UDP, o da un apposito demone, \cmd{klogd}, che estrae i messaggi del
+kernel.\footnote{i messaggi del kernel sono tenuti in un buffer circolare e
+ scritti tramite la funzione \func{printk}, analoga alla \func{printf} usata
+ in user space; una trattazione eccellente dell'argomento si trova in
+ \cite{LinDevDri}, nel quarto capitolo.}
Il servizio permette poi di trattare i vari messaggi classificandoli
attraverso due indici; il primo, chiamato \textit{facility}, suddivide in
Le \acr{glibc} definiscono una serie di funzioni standard con cui un processo
può accedere in maniera generica al servizio di \textit{syslog}, che però
funzionano solo localmente; se si vogliono inviare i messaggi ad un altro
-sistema occorre farlo esplicitamente con un socket\index{socket} UDP, o
-utilizzare le capacità di reinvio del servizio.
+sistema occorre farlo esplicitamente con un socket UDP, o utilizzare le
+capacità di reinvio del servizio.
La prima funzione definita dall'interfaccia è \funcd{openlog}, che apre una
connessione al servizio di \textit{syslog}; essa in generale non è necessaria
\textit{pathname} del terminale.}
\end{prototype}
-La funzione scrive il \itindex{pathname}\textit{pathname} del terminale di
+La funzione scrive il \itindex{pathname} \textit{pathname} del terminale di
controllo del processo chiamante nella stringa posta all'indirizzo specificato
dall'argomento \param{s}. La memoria per contenere la stringa deve essere
stata allocata in precedenza ed essere lunga almeno
Se si passa come argomento \val{NULL} la funzione restituisce il puntatore ad
una stringa statica che può essere sovrascritta da chiamate successive. Si
-tenga presente che il \itindex{pathname}\textit{pathname} restituito
+tenga presente che il \itindex{pathname} \textit{pathname} restituito
potrebbe non identificare univocamente il terminale (ad esempio potrebbe
essere \file{/dev/tty}), inoltre non è detto che il processo possa
effettivamente aprire il terminale.
Qui vanno le cose su \func{openpty} e compagnia.
-%%% Local Variables:
-%%% mode: latex
-%%% TeX-master: "gapil"
-%%% End:
% LocalWords: kernel multitasking dell'I job control BSD POSIX shell sez group
% LocalWords: foreground process bg fg Di waitpid WUNTRACED pgrp session sched
% LocalWords: SetTermAttr UnSetTermAttr cfsetispeed cfsetospeed cfgetispeed
% LocalWords: cfgetospeed quest'ultime tcsendbreak duration break tcdrain
% LocalWords: tcflush queue TCIFLUSH TCOFLUSH TCIOFLUSH tcflow action TCOOFF
-% LocalWords: TCOON TCIOFF TCION timer openpty
+% LocalWords: TCOON TCIOFF TCION timer openpty Window nochdir
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
\ No newline at end of file
projects / gapil.git / blobdiff