\chapter{User Level \glsxtrshort{io}}
As mentionned in Section~\ref{prev:io}, User-Level \glsxtrshort{io} requires multiplexing the \glsxtrshort{io} operations of many \glspl{thrd} onto fewer \glspl{proc} using asynchronous \glsxtrshort{io} operations. Various operating systems offer various forms of asynchronous operations and as mentioned in Chapter~\ref{intro}, this work is exclusively focuesd on Linux.

\section{Existing options}
Since \glsxtrshort{io} operations are generally handled by the

\subsection{\lstinline|epoll|, \lstinline|poll| and \lstinline|select|}

\subsection{Linux's AIO}



\begin{displayquote}
	AIO is a horrible ad-hoc design, with the main excuse being "other,
	less gifted people, made that design, and we are implementing it for
	compatibility because database people - who seldom have any shred of
	taste - actually use it".

	But AIO was always really really ugly.

	\begin{flushright}
		-- Linus Torvalds\cit{https://lwn.net/Articles/671657/}
	\end{flushright}
\end{displayquote}

Interestingly, in this e-mail answer, Linus goes on to describe
``a true \textit{asynchronous system call} interface''
that does
``[an] arbitrary system call X with arguments A, B, C, D asynchronously using a kernel thread''
in
``some kind of arbitrary \textit{queue up asynchronous system call} model''.
This description is actually quite close to the interface of the interface described in the next section.

\subsection{\texttt{io\_uring}}
A very recent addition to Linux, @io_uring@\cit{io\_uring} is a framework that aims to solve many of the problems listed with the above mentioned solutions.

\subsection{Extra Kernel Threads}\label{io:morethreads}
Finally, if the operating system does not offer any satisfying forms of asynchronous \glsxtrshort{io} operations, a solution is to fake it by creating a pool of \glspl{kthrd} and delegating operations to them in order to avoid blocking \glspl{proc}.

\subsection{Discussion}


\section{Event-Engine}


\section{Interface}