The reason = considers you timeout channels to be equal is that they
are, in fact, the same object. In fact, they may end up being the same
object even with different timeout values:
(identical? (timeout 1) (timeout 2))
;= true
Except I got a false just now with a fresh REPL and same timeout
value... All subsequent invocations return true though, and I'm sure
with a little digging the reason for the false would become clear.
The reason for them being the same object is that timeout goes out of
its way to avoid creating to many timeout channels and will reuse
existing ones if their timeouts are due within a small amount of time
(clojure.core.async.impl.timers/TIMEOUT_RESOLUTION_MS, currently 10
ms) of the requested timeout.
Cheers,
Michał
On 20 November 2013 10:08, Thomas G. Kristensen
<thomas.g.kristen...@gmail.com> wrote:
> Hi all,
>
> I ran into a core.async behaviour that confused me a bit the other day. In
> some of our systems, we need to fire different timeouts, perform actions and
> schedule a new timeout. The problem is, that if the timeouts are of the same
> number of ms, we can't distinguish them, and therefore not keep track of and
> remove them from a set (at least not easily).
>
> That sounds a bit fuzzy. Hopefully this spike will make it clearer what I'm
> trying to say:
>
> (require '[clojure.core.async :refer [chan timeout alts!! alts!]])
>
> (= (chan) (chan))
> ;; false
>
> (= (timeout 1) (timeout 2))
> ;; false
>
> (= (timeout 1) (timeout 1))
> ;; true
>
> (do (loop [ch->v (into {} (for [v [1 2 3]] [(timeout 1000) v]))]
> (when-let [chs (keys ch->v)]
> (let [[_ ch] (alts!! chs)]
> (println (ch->v ch))
> (recur (dissoc ch->v ch)))))
> (println "done"))
> ;; only fires "3", the last channel in the map
>
> The intended behaviour of the last loop is to print 1, 2 and 3 (not
> necessarily in that order). However, the ch->v map will only contain one
> key, as timeouts with the same duration are considered the same value. In
> the real example, a new timeout with the same value should be scheduled
> again, by being put in the map.
>
> So, my questions are:
>
> - Is this intended behaviour?
> - Is there a different pattern for achieving the scheduling behaviour I'm
> looking for?
>
> Thanks for your help,
>
> Thomas
>
> --
> --
> 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/groups/opt_out.
--
--
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/groups/opt_out.
