Changeset 912ccbcf for doc/theses/thierry_delisle_PhD/comp_II

Timestamp:

Apr 15, 2020, 2:59:59 PM (4 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

0a6da484

Parents:

4ea5308

Message:

Wrote all missings sections of comp-II

Location:

doc/theses/thierry_delisle_PhD/comp_II

Files:

• comp_II.tex (modified) (2 diffs)
• local.bib (modified) (3 diffs)

doc/theses/thierry_delisle_PhD/comp_II/comp_II.tex

@@ -447 +447 @@
 $select$ entails significant complexity and is being replaced in UNIX operating-systems, which make it a less interesting alternative.
 Another popular interface is $epoll$\cite{epoll}, which is supposed to be cheaper than $select$.
-However, $epoll$ also does not handle the file system and seems to have problem to linux pipes and $TTY$s\cit.
+However, $epoll$ also does not handle the file system and anectodal evidence suggest it has problem with linux pipes and $TTY$s.
+A popular cross-platform alternative is $libuv$\cite{libuv}, which offers asynchronous sockets and asynchronous file system operations (among other features).
+However, as a full-featured library it includes much more than I need and could conflict with other features of \CFA unless significant effort is made to merge them together.
 A very recent alternative that I am investigating is $io_uring$\cite{io_uring}.
-It claims to address some of the issues with $epoll$ but is too recent to be confident that it does.
-Finally, a popular cross-platform alternative is $libuv$\cite{libuv}, which offers asynchronous sockets and asynchronous file system operations (among other features).
-However, as a full-featured library it includes much more than I need and could conflict with other features of \CFA unless significant effort is made to merge them together.
+It claims to address some of the issues with $epoll$ and my early investigating suggest that the claim is accurate.
+$io_uring$ uses a much more general approach where system calls are register to a queue and later executed by the kernel, rather than relying on system calls to return an error instead of blocking and subsequently waiting for changes on file descriptors.
+I believe this approach allows for fewer problems, \eg the manpage for $open$\cite{open} states:
+\begin{quote}
+        Note that [the $O_NONBLOCK$ flag] has no effect for regular files and block devices;
+        that is, I/O operations will (briefly) block when device activity is required, regardless of whether $O_NONBLOCK$ is set.
+        Since $O_NONBLOCK$ semantics might eventually be implemented, applications should not depend upon blocking behavior when specifying this flag for regular files and block devices.
+\end{quote}
+This makes approach based on $epoll$/$select$ less reliable since they may not work for every file descriptors.
+For this reason, I plan to use $io_uring$ as the OS abstraction for the \CFA runtime, unless further work shows problems I haven't encountered yet.
+However, only a small subset of the features are available in Ubuntu as of April 2020\cite{wiki:ubuntu-linux}, which will limit performance comparisons.
+I do not believe this will affect the comparison result.
 
 \paragraph{Event Engine}
@@ -477 +488 @@
 % ===============================================================================
 \section{Discussion}
-
+I believe that runtime system and scheduling are still open topics.
+Many ``state of the art'' production frameworks still use single threaded event-loops because of performance considerations, \eg \cite{nginx-design}, and, to my knowledge, no wideyl available system language offers modern threading facilities.
+I believe the proposed work offers a novel runtime and scheduling package, where existing work only offers fragments that users must assemble themselves when possible.
 
 % ===============================================================================
 % ===============================================================================
 \section{Timeline}
-
+\begin{center}
+\begin{tabular}{ | r @{--} l | p{4in} | }
+\hline May 2020 & October 2020   & Creation of the performance benchmark. \\
+\hline November 2020 & March 2021   & Completion of the implementation. \\
+\hline March 2021 & April 2021  & Final Performance experiments. \\
+\hline May 2017 & August 2021 & Thesis writing and defense. \\
+\hline
+\end{tabular}
+\end{center}
 
 % B I B L I O G R A P H Y

doc/theses/thierry_delisle_PhD/comp_II/local.bib

@@ -265 +265 @@
 % Linux Man Pages
 % ===============================================================================
+@manual{open,
+  title      = "open(2) Linux User's Manual",
+  year       = "2020",
+  month      = "February",
+}
+
 @manual{epoll,
   title      = "epoll(7) Linux User's Manual",
@@ -306 +312 @@
   author={KARSTEN, MARTIN},
   journal={URL: https://git.uwaterloo.ca/mkarsten/libfibre}
+}
+
+@misc{nginx-design,
+  title={Inside NGINX: How We Designed for Performance \& Scale},
+  url = "https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/",
 }
 
@@ -335 +346 @@
    note = "[Online; accessed 14-April-2020]"
  }
+
+ @misc{wiki:ubuntu-linux,
+   author = "{Wikipedia contributors}",
+   title = "Ubuntu version history : Table of versions --- {W}ikipedia{,} The Free Encyclopedia",
+   year = "2020",
+   url = "https://en.wikipedia.org/wiki/Ubuntu_version_history#Table_of_versions",
+   note = "[Online; accessed 15-April-2020]"
+ }