dhil/phd-dissertation
1
0
Fork 0
mirror of https://github.com/dhil/phd-dissertation synced 2026-03-13 02:58:26 +00:00
Code Issues Releases Wiki Activity

Dedication.

Browse Source
This commit is contained in:
Daniel Hillerström
2020-10-13 21:19:48 +01:00
parent 5e602afb68
commit 003c8e4d6c
1 changed files with 13 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
thesis.tex
View File

@@ -201,7 +201,8 @@
%% Finally, a dedication (this is optional -- uncomment the following line if %% Finally, a dedication (this is optional -- uncomment the following line if
%% you want one). %% you want one).
% \dedication{To my mummy.} % \dedication{To my mummy.}
\dedication{\emph{To be or to do}} % \dedication{\emph{To be or to do}}
\dedication{\emph{Bara du sätter gränserna}}
% \begin{preface} % \begin{preface}
% A preface will possibly appear here\dots % A preface will possibly appear here\dots
@@ -2745,18 +2746,18 @@ that computation gets interleaved.
\paragraph{Interruption via interception} \paragraph{Interruption via interception}
% %
To implement process preemption modern-day operating systems typically To implement process preemption operating systems typically to rely on
to rely on the underlying hardware to asynchronously generate some the underlying hardware to asynchronously generate some kind of
kind of interruption signals. These signals can be caught by the interruption signals. These signals can be caught by the operating
operating system's process scheduler, which can then decide to which system's process scheduler, which can then decide to which processes
processes to suspend and continue. to suspend and continue.
% %
If our core calculi had an integrated notion of asynchrony and effects If our core calculi had an integrated notion of asynchrony and effects
along the lines of \citeauthor{AhmanP20}'s core calculus along the lines of \citeauthor{AhmanP20}'s core calculus
$\lambda_{\text{\ae}}$~\cite{AhmanP20}, then we could possibly treat $\lambda_{\text{\ae}}$~\cite{AhmanP20}, then we could possibly treat
interruption signals as asynchronous effectful operations, which can interruption signals as asynchronous effectful operations, which can
occur spontaneously and be handled by some user-definable occur spontaneously and, as suggested by \citet{DolanEHMSW17}, be
handler~\cite{DolanEHMSW17}. handled by a user-definable handler.
% %
In the absence of asynchronous effects we have to inject synchronous In the absence of asynchronous effects we have to inject synchronous
@@ -2765,7 +2766,10 @@ interruptions ourselves.
One extreme approach is to trust the user to perform invocations of One extreme approach is to trust the user to perform invocations of
$\Interrupt$ periodically. $\Interrupt$ periodically.
% %
Another approach is to bundle $\Interrupt$ with invocations of other Another approach is based on the fact that every effect (except for
divergence) occurs via some operation invocation, and every-so-often
the user is likely to perform computational effect, thus the basic
idea is to bundle $\Interrupt$ with invocations of other
operations. For example, we can insert an instance of $\Interrupt$ in operations. For example, we can insert an instance of $\Interrupt$ in
some of the wrapper functions for operation invocations that we have some of the wrapper functions for operation invocations that we have
defined so conscientiously thus far. The problem with this approach is defined so conscientiously thus far. The problem with this approach is