Index: doc/theses/thierry_delisle_PhD/thesis/text/io.tex
===================================================================
--- doc/theses/thierry_delisle_PhD/thesis/text/io.tex	(revision e6662f590f237543e5849fb87dd9039be9203692)
+++ doc/theses/thierry_delisle_PhD/thesis/text/io.tex	(revision 0809c4e7ffedf25a865e4c49f15383b9927127ab)
@@ -455,7 +455,7 @@
 The following sections discuss some useful options using @read@ as an example.
 The standard Linux interface for C is :
-\begin{lstlisting}
+\begin{cfa}
 ssize_t read(int fd, void *buf, size_t count);
-\end{lstlisting}
+\end{cfa}
 
 \subsection{Replacement}
@@ -471,7 +471,7 @@
 Another interface option is to offer an interface different in name only.
 For example:
-\begin{lstlisting}
+\begin{cfa}
 ssize_t cfa_read(int fd, void *buf, size_t count);
-\end{lstlisting}
+\end{cfa}
 This approach is feasible and still familiar to C programmers.
 It comes with the caveat that any code attempting to use it must be recompiled, which is a problem considering the amount of existing legacy C binaries.
@@ -481,7 +481,7 @@
 \subsection{Asynchronous Extension}
 A fairly traditional way of providing asynchronous interactions is using a future mechanism~\cite{multilisp}, \eg:
-\begin{lstlisting}
+\begin{cfa}
 future(ssize_t) read(int fd, void *buf, size_t count);
-\end{lstlisting}
+\end{cfa}
 where the generic @future@ is fulfilled when the read completes and it contains the number of bytes read, which may be less than the number of bytes requested.
 The data read is placed in @buf@.
@@ -489,7 +489,7 @@
 Hence, the buffer cannot be reused until the operation completes but the synchronization does not cover the buffer.
 A classical asynchronous API is:
-\begin{lstlisting}
+\begin{cfa}
 future([ssize_t, void *]) read(int fd, size_t count);
-\end{lstlisting}
+\end{cfa}
 where the future tuple covers the components that require synchronization.
 However, this interface immediately introduces memory lifetime challenges since the call must effectively allocate a buffer to be returned.
@@ -498,8 +498,8 @@
 \subsection{Direct \lstinline{io_uring} Interface}
 The last interface directly exposes the underlying @io_uring@ interface, \eg:
-\begin{lstlisting}
+\begin{cfa}
 array(SQE, want) cfa_io_allocate(int want);
 void cfa_io_submit( const array(SQE, have) & );
-\end{lstlisting}
+\end{cfa}
 where the generic @array@ contains an array of SQEs with a size that may be less than the request.
 This offers more flexibility to users wanting to fully utilize all of the @io_uring@ features.
Index: doc/theses/thierry_delisle_PhD/thesis/text/practice.tex
===================================================================
--- doc/theses/thierry_delisle_PhD/thesis/text/practice.tex	(revision e6662f590f237543e5849fb87dd9039be9203692)
+++ doc/theses/thierry_delisle_PhD/thesis/text/practice.tex	(revision 0809c4e7ffedf25a865e4c49f15383b9927127ab)
@@ -6,5 +6,5 @@
 
 In detail, \CFA supports adding \procs using the type @processor@, in both RAII and heap coding scenarios.
-\begin{lstlisting}
+\begin{cfa}
 {
 	processor p[4]; // 4 new kernel threads
@@ -15,5 +15,5 @@
 	... // execute on 4 processors
 } // delete 4 kernel threads
-\end{lstlisting}
+\end{cfa}
 Dynamically allocated processors can be deleted an any time, \ie their lifetime exceeds the block of creation.
 The consequence is that the scheduler and \io subsystems must know when these \procs come in and out of existence and roll them into the appropriate scheduling algorithms.
@@ -68,5 +68,5 @@
 
 \begin{figure}
-\begin{lstlisting}
+\begin{cfa}
 void read_lock() {
 	// Step 1 : make sure no writers in
@@ -92,5 +92,5 @@
 	write_lock = false;
 }
-\end{lstlisting}
+\end{cfa}
 \caption{Specialized Readers-Writer Lock}
 \label{f:SpecializedReadersWriterLock}