closes #2013: Typos in the docs, using parens for arity-0 methods which are not referentially transparent

This commit is contained in:
Heiko Seeberger 2012-04-24 07:59:12 +02:00
parent 80d6618703
commit 0cbee22bf1
2 changed files with 4 additions and 4 deletions

View file

@ -29,7 +29,7 @@ The quintessential feature of actor systems is that tasks are split up and
delegated until they become small enough to be handled in one piece. In doing
so, not only is the task itself clearly structured, but the resulting actors
can be reasoned about in terms of which messages they should process, how they
should react nominally and how failure should be handled. If one actor does not
should react normally and how failure should be handled. If one actor does not
have the means for dealing with a certain situation, it sends a corresponding
failure message to its supervisor, asking for help. The recursive structure
then allows to handle failure at the right level.
@ -41,7 +41,7 @@ trying to keep everything “under the carpet”.
Now, the difficulty in designing such a system is how to decide who should
supervise what. There is of course no single best solution, but there are a few
guide lines which might be helpful:
guidelines which might be helpful:
- If one actor manages the work another actor is doing, e.g. by passing on
sub-tasks, then the manager should supervise the child. The reason is that

View file

@ -49,7 +49,7 @@ object Pi extends App {
var pi: Double = _
var nrOfResults: Int = _
val start: Long = System.currentTimeMillis
val start: Long = System.currentTimeMillis()
//#create-router
val workerRouter = context.actorOf(
@ -66,7 +66,7 @@ object Pi extends App {
nrOfResults += 1
if (nrOfResults == nrOfMessages) {
// Send the result to the listener
listener ! PiApproximation(pi, duration = (System.currentTimeMillis - start).millis)
listener ! PiApproximation(pi, duration = (System.currentTimeMillis() - start).millis)
// Stops this actor and all its supervised children
context.stop(self)
}