On 07/03/2017 11:03 AM, Vitalie Spinu wrote:
Hi,
Async/close! causes deadlocks if its reducer is stalled (e.g. waits for
an event from
another chan).
Consider:
(let [d (chan)
s (chan 1 (map (fn [v]
(println "this:" v)
(println "from d:" (<!! d))
Discussion of locks aside, doing blocking operations like io or <!! or
>!! or basically anything that looks like it blocks and isn't >! or <!
is a very bad idea in a transducer on a channel. You will (eventually)
block the threadpool and get deadlocks. If you must use a transducer
that does blocking operations, you should checkout pipeline-blocking.
pipeline-blocking has a slightly convoluted internal structure exactly
to avoid blocking operations running on the go block threadpool.
The transducer will be executed when publishing to a channel(this is a
little bit squishy, sometimes publishing to a channel doesn't actually
publish because the channel is full and a callback is registered to do
the publishing the next time a consumer takes), if you publish to a
channel with a transducer that blocks from a go-block, then you are
blocking that go block which is bad.
v)))]
(go (>! s 1))
(Thread/sleep 100)
(println "closing s")
(async/close! s))
;; =>
;; this: 1
;; closing s
;; .. [lock]
This is caused by (.lock mutex) in close! method here:
https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/channels.clj#L247
I wonder if it is there "by design" or a bug. IMO it makes little sense
to lock
external code simply because chan's reducer function is stalled. Just as
close!
doesn't lock on pending puts it shouldn't stall on pending "half-puts".
I need this for systems with inter-dependent chans. In the above example
component 'd' is a dependency of 's', then system will halt in reverse
order of
dependencies closing `s` first.
Thank you,
Vitalie
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with
your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to clojure+unsubscr...@googlegroups.com
<mailto:clojure+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
