Closing a tap without a pending item is OK but closing a tap with a pending item blocks the mult input channel:
Comment made by: klauswuestefeld
A more general case:
(go (println (>! c 42)))
and then closing c will cause the >! to block, instead of returning false.
If c is closed before that, >! will return false.
Is this race condition the intended behavior?
As far as I could understand, the `close!` implementation follows all `take`s and run their respective callbacks for releasing.
The approach I follow was doing the same for `put`s, so we guarantee previously parked `put` will be release - like demonstrated by the general case of this error.
In the same patch, I added a single test to assert this behavior and ported the same code to ClojureScript implementation. I could split both impls on different patches, but I judged having everything together will ease the screening.