frereth.cp.message.to-child — com.frereth/cp 0.0.3-g3b13aae

Looks like this may not be needed at all

Pretty much everything that might have been interesting really seems to belong in from-parent.

Or in the callback that got handed to message as part of its constructor.

Although there is the bit about closing the pipe to the child at the bottom of each event loop.

build-gap-buffer clj

(build-gap-buffer)

callback-threshold-error clj

Signal error if calling back to child w/ incoming message takes much too long (in milliseconds)

callback-threshold-warning clj

Warn if calling back to child w/ incoming message takes too long (in milliseconds)

close-parent-input! clj

(close-parent-input! {:keys [:frereth.cp.message.specs/from-parent-trigger
                             :frereth.cp.message.specs/to-child-done?]
                      :as io-handle})

consolidate-gap-buffer clj

(consolidate-gap-buffer {{:keys [:frereth.cp.message.specs/gap-buffer]
                          :as incoming}
                           :frereth.cp.message.specs/incoming
                         :keys [:frereth.cp.message.specs/message-loop-name]
                         :as state})

consolidate-message-block clj

(consolidate-message-block
  {{:keys [:frereth.cp.message.specs/->child-buffer
           :frereth.cp.message.specs/gap-buffer
           :frereth.cp.message.specs/contiguous-stream-count]
    :as incoming}
     :frereth.cp.message.specs/incoming
   :keys [:frereth.cp.message.specs/message-loop-name]
   log-state :frereth.weald.specs/state
   :as state}
  k-v-pair)

Move the parts of the gap-buffer that are ready to write to child

Really only meant as a helper refactored out of consolidate-gap-buffer

forward! clj

(forward! {:keys [:frereth.cp.message.specs/from-parent]
           parent-trigger :frereth.cp.message.specs/from-parent-trigger
           :as io-handle}
          {:keys [:frereth.cp.message.specs/message-loop-name]
           original-incoming :frereth.cp.message.specs/incoming
           log-state :frereth.weald.specs/state
           :as state})

Trigger the parent-monitor 'loop'

pop-map-first clj

(pop-map-first associative)

Pop first entry from a map. Only makes sense if sorted

possibly-close-stream! clj

(possibly-close-stream!
  {:keys [:frereth.cp.message.specs/from-parent-trigger] :as io-handle}
  {{:keys [:frereth.cp.message.specs/contiguous-stream-count
           :frereth.cp.message.specs/receive-eof
           :frereth.cp.message.specs/receive-total-bytes
           :frereth.cp.message.specs/receive-written]
    :as incoming}
     :frereth.cp.message.specs/incoming
   log-state :frereth.weald.specs/state
   :as state})

Maybe signal child that it won't receive anything else

start-parent-monitor! clj

(start-parent-monitor!
  {:keys [:frereth.weald.specs/logger :frereth.cp.message.specs/child-in
          :frereth.cp.message.specs/message-loop-name]
   trigger-stream :frereth.cp.message.specs/from-parent-trigger
   :as io-handle}
  parent-log
  cb)

This is probably a reasonable default for many/most use cases

trigger-from-parent! clj

(trigger-from-parent! {:keys [:frereth.weald.specs/logger
                              :frereth.cp.message.specs/message-loop-name]
                       :as io-handle}
                      buffer
                      cb
                      {:keys [:frereth.cp.message.to-child/result-writer
                              :frereth.cp.message.specs/bs-or-eof]
                       my-logs :frereth.weald.specs/state
                       :as trigger})

Stream handler for coping with bytes sent by parent

write-bytes-to-child-stream! clj

(write-bytes-to-child-stream! parent-trigger
                              {log-state :frereth.weald.specs/state :as state}
                              buf)

Forward the byte-array inside the buffer