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... On May 19, 2014, at 2:36 PM, Timothy Baldridge wrote: > 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 > > > On Mon, May 19, 2014 at 12:23 PM, Dylan Butman <dbut...@gmail.com> wrote: > 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? > > > > -- > 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. > > > > -- > “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) > > -- > 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 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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
