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