Revisited 3.4 and 3.5.1

This commit is contained in:
Niklas Landin 2011-05-12 22:35:12 +02:00
parent eb3f89aa02
commit 2519e562fc

View file

@ -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