Corretta figura e sistemata la footnote su chi parte prima dopo una fork

[gapil.git] / prochand.tex

diff --git a/prochand.tex b/prochand.tex
index da691436fc01790c4fb7a357c19fcd9d68bcfd71..70d7eb1d2e90ce7d0fd54c5b4f30b6eb6efb4483 100644 (file)
--- a/prochand.tex
+++ b/prochand.tex
@@ -437,15 +437,16 @@ Go to next child
 
 Esaminiamo questo risultato: una prima conclusione che si può trarre è non si
 può dire quale processo fra il padre ed il figlio venga eseguito per
-primo\footnote{anche se nel kernel 2.4.x era stato introdotto un meccanismo
-  che metteva in esecuzione sempre il xxx per primo (TODO recuperare le
-  informazioni esatte)} dopo la chiamata a \func{fork}; dall'esempio si può
-notare infatti come nei primi due cicli sia stato eseguito per primo il padre
-(con la stampa del \acr{pid} del nuovo processo) per poi passare
-all'esecuzione del figlio (completata con i due avvisi di esecuzione ed
-uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al
-ciclo successivo), mentre la terza volta è stato prima eseguito il figlio
-(fino alla conclusione) e poi il padre.
+primo\footnote{a partire dal kernel 2.5.2-pre10 è stato introdotto il nuovo
+  scheduler di Ingo Molnar che esegue sempre per primo il figlio; per
+  mantenere la portabilità è opportuno non fare comunque affidamento su questo
+  comportamento} dopo la chiamata a \func{fork}; dall'esempio si può notare
+infatti come nei primi due cicli sia stato eseguito per primo il padre (con la
+stampa del \acr{pid} del nuovo processo) per poi passare all'esecuzione del
+figlio (completata con i due avvisi di esecuzione ed uscita), e tornare
+all'esecuzione del padre (con la stampa del passaggio al ciclo successivo),
+mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione)
+e poi il padre.
 
 In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di
 scheduling usato dal kernel, dalla particolare situazione in si trova la