results

[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.
 
-\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
@@ -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 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.