Issues
- mult distribution behavior doesn't work as intendedASYNC-127Resolved issue: ASYNC-127
- When a channel is closed, pending takes are committed, but pending puts are not, stranding handlersASYNC-125Resolved issue: ASYNC-125andrewhr
- Race condition when closing multsASYNC-64
- mult channel deadlocks when untapping a consuming channel whilst messages are being queued/blockedASYNC-58
4 of 4
mult distribution behavior doesn't work as intended
Fixed
Description
Environment
None
Attachments
1
Details
Assignee
UnassignedUnassignedReporter
Leon GrapenthinLeon GrapenthinLabels
Approval
TriagedPatch
CodePriority
Major
Details
Details
Assignee
Unassigned
UnassignedReporter
Leon Grapenthin
Leon GrapenthinLabels
Approval
Triaged
Patch
Code
Priority
MajorCreated June 8, 2015 at 7:51 PM
Updated January 10, 2020 at 6:47 PM
Resolved January 10, 2020 at 4:11 PM
Activity
Show:
Alex MillerJanuary 10, 2020 at 6:47 PM
Released in 0.7.559
Alex MillerJanuary 10, 2020 at 4:11 PM
Patch applied, added additional test
Leon GrapenthinJune 8, 2015 at 7:53 PM
Fixing this for clj/cljs
Quote from docstring: "[...] each tap must accept before the next item is distributed."
(def ch (chan)) (def m (mult ch)) (def t-1 (chan)) (def t-2 (chan)) (def t-3 (chan)) (def t-1-takes (atom [])) (defn log [l] (partial swap! l conj)) (tap m t-1) (tap m t-2) (tap m t-3) (close! t-3) (take! t-1 (log t-1-takes)) (take! t-1 (log t-1-takes)) ;; this take shouldn't be happening before ;; a take on t-2 (put! ch true) (put! ch true) @t-1-takes ;-> [true true] ;; but it does.The reason is that the internal atom dctr is decreased twice when a tapped channel is already closed.