From 5ce1cec2ea9f3dfd611b6f7644df595e9b9e4d44 Mon Sep 17 00:00:00 2001 From: Tony Garnock-Jones Date: Sun, 27 Aug 2017 08:18:11 -0400 Subject: [PATCH] Better comments. --- .../example-demand-matcher-glitch-bug.rkt | 42 ++++++++++++------- .../example-demand-matcher-glitch-bug2.rkt | 14 ++++--- 2 files changed, 36 insertions(+), 20 deletions(-) diff --git a/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug.rkt b/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug.rkt index 1e60fe8..1aa1ab9 100644 --- a/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug.rkt +++ b/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug.rkt @@ -1,10 +1,17 @@ #lang syndicate/actor -;; Example showing an interesting design flaw (?) (bug?) in the -;; old-school LLL demand-matcher when demand changes too quickly. The -;; port 6000 server is started, but by the time it starts monitoring -;; demand for its services, the demand is already gone, replaced with -;; demand for port 5999. This causes connections to be accepted on -;; port 6000 going nowhere. +;; Example showing the consequences of not honouring the requirement +;; of the current LLL demand-matcher that supply tasks must *reliably* +;; terminate when their demand is not present. In this case, demand +;; changes too quickly: it exists for long enough to start the task, +;; but is withdrawn before the task itself has a chance to detect it. +;; Because the task (as currently implemented) does not use the "learn +;; negative knowledge" pattern to detect the *absence* of some +;; assertion, it does not terminate as it is supposed to. +;; +;; Specifically, here, the port 6000 server is started, but by the +;; time it starts monitoring demand for its services, the demand is +;; already gone, replaced with demand for port 5999. This causes +;; connections to be accepted on port 6000 going nowhere. ;; ;; One "fix" is to use #:assertions to give the TCP listener actor ;; some initial interests, thus transferring responsibility @@ -12,15 +19,22 @@ ;; this doesn't completely eliminate all possible instances where ;; demand may change too quickly. See example-demand-matcher-glitch-bug2.rkt. ;; -;; A speculative idea is to use a kind of contract-monitor to enforce -;; the invariant that demand *cannot* fluctuate too rapidly. One might -;; write that "if (listen 6000) is asserted, then if (listen 6000) is -;; retracted, (observe (listen 6000)) must have been asserted in the -;; causal history of the retraction", but what does "causal history" -;; mean, precisely? And how can it be soundly and efficiently tracked? +;; Of course, the real "fix" is for the TCP listener actor to use a +;; `flush!` to robustly detect that demand for its services no longer +;; exists even at startup time. ;; -;; The only "fix" that both solves the problem and is currently -;; implementable that I have thought of is to modify the +;; A speculative idea, if we set aside the (in principle) documented +;; requirement that the LLL demand-matcher places on its supply tasks, +;; is to use a kind of contract-monitor to enforce the invariant that +;; demand *cannot* fluctuate too rapidly. One might write that "if +;; (listen 6000) is asserted, then if (listen 6000) is retracted, +;; (observe (listen 6000)) must have been asserted in the causal +;; history of the retraction", but what does "causal history" mean, +;; precisely? And how can it be soundly and efficiently tracked? +;; +;; The only "fix" that solves the problem, is currently implementable, +;; and allows supply tasks to escape responsibility for noticing their +;; own superfluity that I have thought of is to modify the ;; demand-matcher to do something like `during/spawn` is doing, using ;; an auxiliary protocol to centralise tracking of demand and supply ;; at the demand-matcher rather than delegating it to the services. diff --git a/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug2.rkt b/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug2.rkt index a988f39..069efb1 100644 --- a/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug2.rkt +++ b/racket/syndicate/examples/actor/example-demand-matcher-glitch-bug2.rkt @@ -1,10 +1,12 @@ #lang syndicate/actor -;; Example showing an interesting design flaw (?) (bug?) in the -;; old-school LLL demand-matcher when demand changes too quickly. The -;; port 6000 server is started, but by the time it starts monitoring -;; demand for its services, the demand is already gone, replaced with -;; demand for port 5999. This causes connections to be accepted on -;; port 6000 going nowhere. +;; Example showing the consequences of not honouring the requirement +;; of the current LLL demand-matcher that supply tasks must *reliably* +;; terminate when their demand is not present. In this case, demand +;; changes too quickly: it exists for long enough to start the task, +;; but is withdrawn before the task itself has a chance to detect it. +;; Because the task (as currently implemented) does not use the "learn +;; negative knowledge" pattern to detect the *absence* of some +;; assertion, it does not terminate as it is supposed to. ;; ;; Demonstrates that the fix in commit 2a0197b isn't in general ;; sufficient.