From 88ec80487ddd2850fbde95d8a8711f2d44161ee2 Mon Sep 17 00:00:00 2001 From: Tony Garnock-Jones Date: Tue, 7 May 2019 14:02:52 +0100 Subject: [PATCH] Remove unused definition --- syndicate/distributed/client/tcp.rkt | 53 +++++++++++++--------------- 1 file changed, 25 insertions(+), 28 deletions(-) diff --git a/syndicate/distributed/client/tcp.rkt b/syndicate/distributed/client/tcp.rkt index a9c3ee9..d1bc456 100644 --- a/syndicate/distributed/client/tcp.rkt +++ b/syndicate/distributed/client/tcp.rkt @@ -19,34 +19,31 @@ (during/spawn (server-connection ($ address (server-tcp-connection $host $port $scope))) #:name address (define id (list (gensym 'client) host port)) - (let boot-connection () - (define root-facet (current-facet)) - (reassert-on (tcp-connection id (tcp-address host port)) - (retracted (tcp-accepted id)) - (asserted (tcp-rejected id _)) - (retracted (server-transport-connected address))) + (reassert-on (tcp-connection id (tcp-address host port)) + (retracted (tcp-accepted id)) + (asserted (tcp-rejected id _)) + (retracted (server-transport-connected address))) - (during (tcp-accepted id) - (assert (server-transport-connected address)) - (define accumulate! (packet-accumulator (lambda (p) (send! (server-packet address p))))) - (on (message (tcp-in id $bs)) (accumulate! bs))) + (during (tcp-accepted id) + (assert (server-transport-connected address)) + (define accumulate! (packet-accumulator (lambda (p) (send! (server-packet address p))))) + (on (message (tcp-in id $bs)) (accumulate! bs))) - (during (server-transport-connected address) - ;; If we run generic-client-session-facet in the `tcp-accepted` handler above, - ;; then unfortunately disconnection of the TCP socket on error overtakes the error - ;; report itself, terminating the generic-client-session-facet before it has a - ;; chance to handle the error report. - ;; - ;; Could timing errors like that be something a type system could help us with? - ;; The conversation in `server-packet`s is sort-of "nested" inside the - ;; conversation in `tcp-in`s; a single facet reacting to both conversations (in - ;; this instance, to `server-packets` in an implicit frame, but explicitly to the - ;; frame of the `tcp-in`s, namely `tcp-accepted`) is probably an error. Or rather, - ;; any situation where pending "inner conversation" business could be obliterated - ;; by discarding a facet based on "outer conversation" framing is probably an - ;; error. - ;; - (generic-client-session-facet address - scope - (lambda (x) (send! (tcp-out id (encode x))))))))) + (during (server-transport-connected address) + ;; If we run generic-client-session-facet in the `tcp-accepted` handler above, then + ;; unfortunately disconnection of the TCP socket on error overtakes the error report + ;; itself, terminating the generic-client-session-facet before it has a chance to + ;; handle the error report. + ;; + ;; Could timing errors like that be something a type system could help us with? The + ;; conversation in `server-packet`s is sort-of "nested" inside the conversation in + ;; `tcp-in`s; a single facet reacting to both conversations (in this instance, to + ;; `server-packets` in an implicit frame, but explicitly to the frame of the + ;; `tcp-in`s, namely `tcp-accepted`) is probably an error. Or rather, any situation + ;; where pending "inner conversation" business could be obliterated by discarding a + ;; facet based on "outer conversation" framing is probably an error. + ;; + (generic-client-session-facet address + scope + (lambda (x) (send! (tcp-out id (encode x))))))))