Ignore:
Timestamp:
Apr 15, 2020, 2:59:59 PM (20 months ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
arm-eh, jacob/cs343-translation, master, new-ast, new-ast-unique-expr
Children:
0a6da484
Parents:
4ea5308
Message:

Wrote all missings sections of comp-II

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/thierry_delisle_PhD/comp_II/comp_II.tex

    r4ea5308 r912ccbcf  
    447447$select$ entails significant complexity and is being replaced in UNIX operating-systems, which make it a less interesting alternative.
    448448Another popular interface is $epoll$\cite{epoll}, which is supposed to be cheaper than $select$.
    449 However, $epoll$ also does not handle the file system and seems to have problem to linux pipes and $TTY$s\cit.
     449However, $epoll$ also does not handle the file system and anectodal evidence suggest it has problem with linux pipes and $TTY$s.
     450A popular cross-platform alternative is $libuv$\cite{libuv}, which offers asynchronous sockets and asynchronous file system operations (among other features).
     451However, 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.
    450452A very recent alternative that I am investigating is $io_uring$\cite{io_uring}.
    451 It claims to address some of the issues with $epoll$ but is too recent to be confident that it does.
    452 Finally, a popular cross-platform alternative is $libuv$\cite{libuv}, which offers asynchronous sockets and asynchronous file system operations (among other features).
    453 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.
     453It claims to address some of the issues with $epoll$ and my early investigating suggest that the claim is accurate.
     454$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.
     455I believe this approach allows for fewer problems, \eg the manpage for $open$\cite{open} states:
     456\begin{quote}
     457        Note that [the $O_NONBLOCK$ flag] has no effect for regular files and block devices;
     458        that is, I/O operations will (briefly) block when device activity is required, regardless of whether $O_NONBLOCK$ is set.
     459        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.
     460\end{quote}
     461This makes approach based on $epoll$/$select$ less reliable since they may not work for every file descriptors.
     462For 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.
     463However, only a small subset of the features are available in Ubuntu as of April 2020\cite{wiki:ubuntu-linux}, which will limit performance comparisons.
     464I do not believe this will affect the comparison result.
    454465
    455466\paragraph{Event Engine}
     
    477488% ===============================================================================
    478489\section{Discussion}
    479 
     490I believe that runtime system and scheduling are still open topics.
     491Many ``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.
     492I believe the proposed work offers a novel runtime and scheduling package, where existing work only offers fragments that users must assemble themselves when possible.
    480493
    481494% ===============================================================================
    482495% ===============================================================================
    483496\section{Timeline}
    484 
     497\begin{center}
     498\begin{tabular}{ | r @{--} l | p{4in} | }
     499\hline May 2020 & October 2020   & Creation of the performance benchmark. \\
     500\hline November 2020 & March 2021   & Completion of the implementation. \\
     501\hline March 2021 & April 2021  & Final Performance experiments. \\
     502\hline May 2017 & August 2021 & Thesis writing and defense. \\
     503\hline
     504\end{tabular}
     505\end{center}
    485506
    486507% B I B L I O G R A P H Y
Note: See TracChangeset for help on using the changeset viewer.