roy's comments: chapter 5

[msc-thesis1617.git] / conclusion.tex

diff --git a/conclusion.tex b/conclusion.tex
index e493a5b..1b2e533 100644 (file)
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -68,7 +68,7 @@ flow between \gls{mTask}-\glspl{Task}. In this way the new system follows the
 mentioned extension such as the parallel combinator. Others might be achieved
 using simple syntactic transformations.
 
 mentioned extension such as the parallel combinator. Others might be achieved
 using simple syntactic transformations.
 

-\paragraph{Launch \glspl{Task} from a \gls{Task}: }
+\paragraph{Launch \glspl{Task} from a \gls{Task}: }\label{par:tasklaunch}

 Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
 the current system this type of logic has to take place server side. Adding
 this functionality to the bytecode-view allows greater flexibility, easier
 Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
 the current system this type of logic has to take place server side. Adding
 this functionality to the bytecode-view allows greater flexibility, easier


@@ -133,5 +133,5 @@ generating \gls{C} code are not usable for dynamic \gls{Task} environments.
 The dynamic nature also allows the programmer to design fail-over mechanisms.
 When a device is assigned a \gls{Task} but another device suddenly becomes
 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
 The dynamic nature also allows the programmer to design fail-over mechanisms.
 When a device is assigned a \gls{Task} but another device suddenly becomes
 unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to

-the first device that possibly takes over some of the functionality of the
-broken device without needing to recompile the code.
+another device that is also suitable for running the \gls{Task} without needing
+to recompile the code.