Better comments.
This commit is contained in:
parent
d0e803ac41
commit
5ce1cec2ea
|
@ -1,10 +1,17 @@
|
||||||
#lang syndicate/actor
|
#lang syndicate/actor
|
||||||
;; Example showing an interesting design flaw (?) (bug?) in the
|
;; Example showing the consequences of not honouring the requirement
|
||||||
;; old-school LLL demand-matcher when demand changes too quickly. The
|
;; of the current LLL demand-matcher that supply tasks must *reliably*
|
||||||
;; port 6000 server is started, but by the time it starts monitoring
|
;; terminate when their demand is not present. In this case, demand
|
||||||
;; demand for its services, the demand is already gone, replaced with
|
;; changes too quickly: it exists for long enough to start the task,
|
||||||
;; demand for port 5999. This causes connections to be accepted on
|
;; but is withdrawn before the task itself has a chance to detect it.
|
||||||
;; port 6000 going nowhere.
|
;; 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
|
;; One "fix" is to use #:assertions to give the TCP listener actor
|
||||||
;; some initial interests, thus transferring responsibility
|
;; some initial interests, thus transferring responsibility
|
||||||
|
@ -12,15 +19,22 @@
|
||||||
;; this doesn't completely eliminate all possible instances where
|
;; this doesn't completely eliminate all possible instances where
|
||||||
;; demand may change too quickly. See example-demand-matcher-glitch-bug2.rkt.
|
;; 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
|
;; Of course, the real "fix" is for the TCP listener actor to use a
|
||||||
;; the invariant that demand *cannot* fluctuate too rapidly. One might
|
;; `flush!` to robustly detect that demand for its services no longer
|
||||||
;; write that "if (listen 6000) is asserted, then if (listen 6000) is
|
;; exists even at startup time.
|
||||||
;; 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 both solves the problem and is currently
|
;; A speculative idea, if we set aside the (in principle) documented
|
||||||
;; implementable that I have thought of is to modify the
|
;; 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
|
;; demand-matcher to do something like `during/spawn` is doing, using
|
||||||
;; an auxiliary protocol to centralise tracking of demand and supply
|
;; an auxiliary protocol to centralise tracking of demand and supply
|
||||||
;; at the demand-matcher rather than delegating it to the services.
|
;; at the demand-matcher rather than delegating it to the services.
|
||||||
|
|
|
@ -1,10 +1,12 @@
|
||||||
#lang syndicate/actor
|
#lang syndicate/actor
|
||||||
;; Example showing an interesting design flaw (?) (bug?) in the
|
;; Example showing the consequences of not honouring the requirement
|
||||||
;; old-school LLL demand-matcher when demand changes too quickly. The
|
;; of the current LLL demand-matcher that supply tasks must *reliably*
|
||||||
;; port 6000 server is started, but by the time it starts monitoring
|
;; terminate when their demand is not present. In this case, demand
|
||||||
;; demand for its services, the demand is already gone, replaced with
|
;; changes too quickly: it exists for long enough to start the task,
|
||||||
;; demand for port 5999. This causes connections to be accepted on
|
;; but is withdrawn before the task itself has a chance to detect it.
|
||||||
;; port 6000 going nowhere.
|
;; 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
|
;; Demonstrates that the fix in commit 2a0197b isn't in general
|
||||||
;; sufficient.
|
;; sufficient.
|
||||||
|
|
Loading…
Reference in New Issue