BIND 10 trac2775, updated. 9869caead03573be43747c30c4f38929c975b409 [2775] Fixups of text

[BIND 10 source code commits]

The branch, trac2775 has been updated
       via  9869caead03573be43747c30c4f38929c975b409 (commit)
      from  a756e890b5e9dee98694bb88d3714613c0af686e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 9869caead03573be43747c30c4f38929c975b409
Author: Michal 'vorner' Vaner <michal.vaner at nic.cz>
Date:   Mon Mar 11 10:20:38 2013 +0100

    [2775] Fixups of text

-----------------------------------------------------------------------

Summary of changes:
 doc/design/resolver/01-scaling-across-cores |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

-----------------------------------------------------------------------
diff --git a/doc/design/resolver/01-scaling-across-cores b/doc/design/resolver/01-scaling-across-cores
index a471ffe..95f1e91 100644
--- a/doc/design/resolver/01-scaling-across-cores
+++ b/doc/design/resolver/01-scaling-across-cores
@@ -69,8 +69,8 @@ Goals
  * Minimise waiting for locks.
  * Don't require too much memory.
  * Minimise the number of upstream queries (both because they are slow and
-   expensive and also because we don't to eat too much bandwidth and spam the
-   authoritative servers).
+   expensive and also because we don't want to eat too much bandwidth and spam
+   the authoritative servers).
  * Design simple enough so it can be implemented.
 
 Naïve version
@@ -230,7 +230,7 @@ A query is an object once again, with some kind of state machine.
 Then there are two kinds of threads. The peasants are just to do the heavy
 work. There's a global work-queue for peasants. Once a peasant is idle, it
 comes to the queue and picks up a handful of queries from there. It does as
-much each the query as possible without requiring any shared resource.
+much on each the query as possible without requiring any shared resource.
 
 The other kind, the landlords, have a resource to watch over each. So we would
 have a cache (or several parts of cache), the sockets for accepting queries and
@@ -260,6 +260,14 @@ iterate through the queue, calling each functor. The parameter would be to
 allow easy generation of more tasks for other queues (they would be stored
 privately first, and appended to remote queues at the end of batch).
 
+Also, if we wanted to generate multiple parallel upstream queries from a single
+query, we would need to be careful. A query object would not have a lock on
+itself and the upstream queries could end up in a different caches/threads. To
+protect the original query, we would add another landlord that would aggregate
+answers together and let the query continue processing once it got enough
+answers. That way, the answers would be pushed all to the same threads and they
+could not fight over the query.
+
 [NOTE]
 This model would work only with threads, not processes.