From 2519e562fc262d51ca69d0cae2d2c69db458c0fa Mon Sep 17 00:00:00 2001 From: Niklas Landin Date: Thu, 12 May 2011 22:35:12 +0200 Subject: [PATCH] Revisited 3.4 and 3.5.1 --- report.lyx | 50 +++++++++++++++++++++++++------------------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/report.lyx b/report.lyx index 83bb83b..a5d6586 100644 --- a/report.lyx +++ b/report.lyx @@ -5195,7 +5195,7 @@ name "sec:Communication-with-the-GDL-VM" A game launched on the GGS is run within a virtual machine. For each programming language supported, there is a virtual machine which interprets the game. - Furthermore an interface for communication between the GGS, the game and + Furthermore an interface for communication among the GGS, the game and the players playing the game is present. \end_layout @@ -5223,7 +5223,7 @@ localStorage . The game state is safely stored in a database and retrieved for manipulation by a call for the world object. - Interaction with the players is done by using the + Interaction with the players are done by using the \emph on \begin_inset ERT @@ -5320,7 +5320,7 @@ reference "alg:exposing-erlang" \end_layout \begin_layout Standard -In JavaScript is is common to use a top level object, called a global object, +In JavaScript it is common to use a top level object, called a global object, to establish a global scope. This allows the declaration of global variables and functions. To gain access to the global object in the GGS, the @@ -5395,7 +5395,7 @@ localStorage \noun default objects are dummy objects, which provide no functionality, these two objects are simply placed in the GDL for the purpose clearing up the code. - In order to perform an action using the GGS and + To perform an action using the GGS and \noun on localStorage \noun default @@ -5845,7 +5845,7 @@ Techniques for ensuring reliability \end_layout \begin_layout Standard -One of the main goals of the project is to achieve high reliability. +One main goal of the project is to achieve high reliability. The term 'reliable system' is defined by the IEEE as \end_layout @@ -6045,7 +6045,7 @@ key "Savor:1997:HSA:851010.856089" There are several approaches to supervisor design in general (when not just considering how they work in Erlang). One common approach is to have the supervisor look in to the state of the - process(es) it supervises, and let the supervisor make decisions based + process(es) it supervises, and let the supervisor makes decisions based on this state. The supervisor has a specification of how the process it supervises should function, and this is how it makes decisions. @@ -6053,27 +6053,27 @@ There are several approaches to supervisor design in general (when not just \end_layout \begin_layout Standard -In Erlang, we have a simple version of supervisors. - We do not inspect the state of the processes being supervised. +In Erlang, there is a simple version of supervisors. + It does not inspect the state of the processes being supervised. We do have a specification of how the supervised processes should behave, but on a higher level. - The specification describes things such as how many times in a given time - interval a child process may crash, which processes need restarting when - crashes occur, and so forth. + The specification describes things such as how many times in a given interval + a child process may crash, which processes need restarting when crashes + occur, and so forth. \end_layout \begin_layout Standard -When the linking of processes in order to monitor exit behavior is coupled - with the transparent distribution of Erlang, a very powerful supervision - system is created. - For instance, we can restart a failing process on a different, new node, - with minimal impact on the system as a whole. +When the linking of processes to monitor exit behavior is coupled with the + transparent distribution of Erlang, a very powerful supervision system + is created. + For instance, it is possible to restart a failing process on a different, + new node, with minimal impact on the system as a whole. \end_layout \begin_layout Standard -In the GGS, we have separated the system in to two large supervised parts. +In the GGS, the system is separated into two large supervised parts. We try to restart a crashing child separately, if this fails too many \begin_inset Foot status collapsed @@ -6103,28 +6103,28 @@ The graphic above shows our two subsystems, the coordinator subsystem and the dispatcher subsystem. Since these two systems perform very different tasks they have been separated. Each subsystem has one worker process, the coordinator or the dispatcher. - The worker process keeps a state which should not be lost upon a crash. + The worker process keeps a state which should not be lost on a crash. \end_layout \begin_layout Standard -We have chosen to let faulty processes crash very easily when they receive - bad data, or something unexpected happens. - The alternative to crashing would have been to try and fix this faulty - data, or to foresee the unexpected events. +We have chosen to let faulty processes crash easily when they receive bad + data, or if something unexpected happens. + The alternative to crashing would have been to try to fix this faulty data, + or to foresee the unexpected events. We chose not to do this because it is so simple to monitor and restart - processes, and so difficult to try and mend broken states. + processes, and so difficult to try to mend broken states. This approach is something widely deployed in the Erlang world, and developers are often encouraged to “Let it crash”. \end_layout \begin_layout Standard -To prevent any data loss, the good state of the worker processes is stored +To prevent any data loss, the good state of the worker processes are stored in their respective backup processes. When a worker process (re)starts, it asks the backup process for any previous state, if there is any that state is loaded in to the worker and it proceeds where it left off. If on the other hand no state is available, a special message is delivered - instead, making the worker create a new state, this is what happens when + instead, making the worker creates a new state, this is what happens when the workers are first created. \end_layout