Re-evaluating recuring go blocks

[Dylan Butman]

When working with channels and go blocks with nRepl, I often want to do something like this.

(def events (event-generator))

(go-loop []

         (when-let [event (<! events)]

           (handle-event event)

           (recur)))

Sometime later I want to stop listening, so I

(close! events)

This is fine, but I often find myself with a lot of boilerplate around go blocks where I'm constantly closing the channel, redefining it, and then re-evaluating the go-block just to try a different behavior. If you re-evaluate the go-block without closing the channel, you'll get duplicate actions. Additionally, if your channel drops out of scope, or you didn't set an exit condition on the go block (using while true or something similar), you can end up with indefinite operations that are impossible to kill without restarting the repl (and does this actually stop the code from continuing to execute somewhere in java)?

I'm not very familiar with garbage collection, but is there some way to garbage collect blocks that have been re-evaluated? Does the treatment of re-evaluation depend on scope, ie. if you wrap it in a function, will it make a difference? 

I can imagine some function or macro that might close! and then re-create a channel everytime it's is called, maybe something like,

(defn my-chan (atom (chan)))

(defn test-chan []

  (close! @my-chan)

  (reset! my-chan (event-generator))

  (go-loop []

           (when-let [event (<! events)]

             (handle-event event)

             (recur))))

But that doesn't really seem to reduce the complexity, since you'd have to define an atom for each of these types of functions. 

Thoughts?

Best

Dylan

[Herwig Hochleitner]

I always pass a control-channel into go loops, by which I can close it:

(defn looper [event-ch ctl-ch]

  (go-loop []

    (alt! event-ch ([event _] (handle-event event) (recur))

          ctl-ch   ([msg _] (assert (nil? msg))))))

This also makes it easy to funnel more control events then just end-of-life into the loop.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Timothy Baldridge]

Also, go blocks that are waiting on channels that are garbage collected will be garbage collected themselves. This means I often just re-compile an entire namespace, this redefines the channel, re-binds the def the channel is attached to, and recreates all gos. The channel is now free go be GC'd along with any go's attached. 

Another idea is to keep all the logic out of the go blocks, and instead keep it inside a defn. Then you can simply redefine the defn and the next time to go calls the defn it will use the new version. 

Timothy

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Dylan Butman]

Great!

I've used alts! before with control channels which is definitely useful as well. 

Timothy, can you elaborate a little? I'm still a little unclear when channels are garbage collected. It it an issue to leave channels open after you've stopped using them? I always feel a little strange constantly creating new channels to replace callbacks, blocking on their output, and then wondering whether or not I need to worry about closing them. If a channel falls out of scope is it garbage collected? How do go blocks affect scoping? 

[Timothy Baldridge]

Channels are not tied to anything, so once your code stops referencing them, they are garbage collected. 

Go blocks are actually nothing more than pretty callbacks that are attached to channels. So if a go is waiting for a put or a take from a channel, it will be GC'd with the channel. I could go into the details here, but I'll say it this way: if a channel could ever have a value again, it will not be GC'd if there's no possible way for the channel to receive a value, then it will be GC'd at some point. 

For example:

(dotimes [x 100]

  (let [c (chan)]
   (dotimes [x 10]
     (go (<! c)))))

Here, all these gos will be GC'd they are parked on the channel, but the channel can never give them a value, so once the channel is GC'd all the gos will as well. 

You can (ab)use this by simply re-defining your channels when you want to throw away new state. The new channel will replace the old, and that channel will be GC'd along with all the GOs that are waiting on it. 

Now, this is all a bit different if you use the (thread) macro. In that case threads are not GC'd (since the OS is holding on to them) so you'll need to shut those down on your own. 

Hopefully this  helps. 

Timothy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dylan Butman]

Yea that's very helpful. When you say "the channel can never give them a value," is that because the channel is no longer in scope?

So 

(def c (chan))

(dotimes [x 10]

  (go (<! c)))

would not be GC'd until the entire namespace is reevaluated? Would redefining c here cause the 10 GOs to be GC'd? I feel like I've done this before and ended up with duplicated actions...

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/xGWfw0O9kbU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.