Bug in tcp driver when switching ports

[tonyg]

#lang syndicate/actor
;; Example showing a bug when changing listen port. Connect after the
;; switch to port 5998. You will see two "Welcome" messages! You
;; should only see one. The TCP driver is spawning *two* listeners for
;; the new port, when only one should exist.

(require syndicate/protocol/advertise)
(require/activate syndicate/drivers/tcp)
(require (only-in racket/port read-bytes-line-evt))

(file-stream-buffer-mode (current-output-port) 'none)
(define stdin-evt (read-bytes-line-evt (current-input-port) 'any))

(struct listen-port (number) #:prefab) ;; assertion

(spawn (during (listen-port $port)
         (define server-id (tcp-listener port))
         (assert (advertise (observe (tcp-channel _ server-id _))))
         (during/spawn (advertise (tcp-channel $c server-id _))
                       (assert (advertise (tcp-channel server-id c _)))
                       (on-start
                        (printf "Accepted connection from ~v on port ~a\n" c port)
                        (send! (tcp-channel server-id c
                                            (string->bytes/utf-8
                                             (format "Welcome! You connected to port ~a.\n"
                                                     port)))))
                       (on (message (tcp-channel c server-id $bs))
                           (printf "Discarding input ~v from ~v on port ~a\n" bs c port))
                       (on-stop (printf "Closed connection ~v on port ~a\n" c port)))))

(spawn* (printf "Asserting port 5999...\n")
        (assert! (listen-port 5999))
        (flush!)
        (retract! (listen-port 5999))
        (printf "Switching to port 5998...\n")
        (react
         (assert (listen-port 5998))))

[tonyg]

This one's a doozy. There are two problems:

• the initial port 6000 listener survives forever because it never sees retraction of demand. (The retraction is already processed by the time the supply gets to see anything.)
• the 5998 listener is being spawned twice by the demand-matcher, because of a very old demand-matcher bug that so far hasn't manifested.

The former problem I'm punting on for the moment.

The latter:

• the bug manifested because a single patch described both the drop in demand for 5999 and rise in demand for 5998
• the default-task-supervisor was called (correctly) for both the rise and drop
• but there was confusion in how the actions-accumulator was to be treated!
• the outermost code assumed that new actions were to be returned and consed on to the old actions
• but the innermost code was threading the actions through, appending new actions to it
• therefore, a single spawn action for 5998 was correctly being generated
• but incorrectly duplicated because of the mismatch in assumptions.

Upcoming patch harmonizes the treatment of the action-accumulator, and sure enough the double-listener goes away.