Changeset 0809c4e for doc/theses/thierry_delisle_PhD/thesis/text/io.tex

Timestamp:

Jul 23, 2022, 5:33:57 PM (2 years ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ADT, ast-experimental, master, pthread-emulation, qualifiedEnum

Children:

c4072d8e

Parents:

b9e2b87

git-author:

Peter A. Buhr <pabuhr@…> (07/23/22 17:32:58)

git-committer:

Peter A. Buhr <pabuhr@…> (07/23/22 17:33:57)

Message:

change lstlisting macro to cfa

File:

• doc/theses/thierry_delisle_PhD/thesis/text/io.tex (modified) (5 diffs)

doc/theses/thierry_delisle_PhD/thesis/text/io.tex

@@ -455 +455 @@
 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 +471 @@
 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 +481 @@
 \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 +489 @@
 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 +498 @@
 \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.