Index: doc/theses/thierry_delisle_PhD/thesis/text/practice.tex
===================================================================
--- doc/theses/thierry_delisle_PhD/thesis/text/practice.tex	(revision 6b06abe1b96b58a5aefdfe75542b2eb8b0bac921)
+++ doc/theses/thierry_delisle_PhD/thesis/text/practice.tex	(revision bfd551277c04ecd8721e431ae84ab67dfad0fd2b)
@@ -95,6 +95,27 @@
 
 \section{Idle-Sleep}
+In addition to users manually changing the number of \procs, it is desireable to support ``removing'' \procs when there is not enough \ats for all the \procs to be useful.
+While manual resizing is expected to be rare, the number of \ats is expected to vary much more which means \procs may need to be ``removed'' for only short periods of time.
+Furthermore, race conditions that spuriously lead to the impression no \ats are ready are actually common in practice.
+Therefore \procs should not be actually \emph{removed} but simply put into an idle state where the \gls{kthrd} is blocked until more \ats become ready.
+This state is referred to as \newterm{Idle-Sleep}.
 
-\subsection{Tracking Sleepers}
+Idle sleep effectively encompasses several challenges.
+First some data structure needs to keep track of all \procs that are in idle sleep.
+Because of idle sleep can be spurious, this data structure has strict performance requirements in addition to the strict correctness requirements.
+Next, some tool must be used to block kernel threads \glspl{kthrd}, \eg \texttt{pthread\_cond\_wait}, pthread semaphores.
+The complexity here is to support \at parking and unparking, timers, \io operations and all other \CFA features with minimal complexity.
+Finally, idle sleep also includes a heuristic to determine the appropriate number of \procs to be in idle sleep an any given time.
+This third challenge is however outside the scope of this thesis because developping a general heuristic is involved enough to justify its own work.
+The \CFA scheduler simply follows the ``Race-to-Idle'\cit{https://doi.org/10.1137/1.9781611973099.100}' approach where a sleeping \proc is woken any time an \at becomes ready and \procs go to idle sleep anytime they run out of work.
+
+
+\section{Tracking Sleepers}
+Tracking which \procs are in idle sleep requires a data structure holding all the sleeping \procs, but more importantly it requires a concurrent \emph{handshake} so that no \at is stranded on a ready-queue with no active \proc.
+The classic challenge is when a \at is made ready while a \proc is going to sleep, there is a race where the new \at may not see the sleeping \proc and the sleeping \proc may not see the ready \at.
+
+Furthermore, the ``Race-to-Idle'' approach means that there is some
+
+\section{Sleeping}
 
 \subsection{Event FDs}
@@ -104,3 +125,3 @@
 \subsection{\texttt{io\_uring}}
 
-\subsection{Reducing Latency}
+\section{Reducing Latency}