Hi Timothy, That's very cool and very good to know!
Cheers, M. On 12 July 2013 00:56, Timothy Baldridge <tbaldri...@gmail.com> wrote: > It's interesting to note that blocking go blocks can actually be GC'd. For > example, run this in a repl: > > (loop [] (let [c (chan)] > (go (>! c 42))) > (recur)) > > On my box the CPU and memory spikes, but after I CTRL+C and kill the loop, > the GC kicks in and collects all the channels and gos > > When go's are parked, they are put into a queue on the channel, thus when > the channel is unreachable (besides inside the go block) both are collected, > and the thread of execution is effectively terminated. > > > > Timothy > > > On Thu, Jul 11, 2013 at 4:53 PM, Michał Marczyk <michal.marc...@gmail.com> > wrote: >> >> I think you could pass the producer a higher-order (chan 1) with the >> actual communication channel placed in the buffer. >> >> Then at each step the producer would do >> >> (when-let [c (<! communication-channel)] >> (>! c (rand)) >> (>! communication-channel c)) >> >> Once you close communication-channel, the put succeeds, but then the >> take on communication-channel returns nil and the producer stops. >> >> Cheers, >> M. >> >> >> On 12 July 2013 00:37, Alex Miller <a...@puredanger.com> wrote: >> > I haven't been in any discussions about this with the team, so it's >> > entirely >> > possible I am ignorant of some established future direction... but >> > >> > - "closed?" seems useful to me. (It may also be useful to ask "drained?" >> > (closed + empty).) >> > - >! returning an indicator of success also seems useful. However, since >> > it >> > executes asynchronously, I suspect adding that functionality may not be >> > feasible (or may be feasible but incur a synchronization or complexity >> > cost >> > that is unacceptable). >> > >> > If you'd like to file a ticket at >> > http://dev.clojure.org/jira/browse/ASYNC >> > that would help to track the request. >> > >> > With respect to other strategies for dealing with this: >> > >> > 1) You could simply ignore the producer. If no one is requesting new >> > values, >> > the producer will not be run and no thread time should be consumed >> > (there is >> > of course heap being used). Not really recommending this but it's an >> > option! >> > >> > 2) You could create a control channel for the producer (and other >> > interested >> > processes) that could transmit a stop message. Then alts! on the control >> > channel in combination with the >! so that you're waiting on either the >> > need >> > to stop or the ability to put a new value in the channel. >> > >> > Alex >> > >> > >> > On Thursday, July 11, 2013 7:16:56 AM UTC-5, vemv wrote: >> >> >> >> Consider a happy, oblivious producer of values: >> >> >> >> (def c (chan 42)) >> >> >> >> (go (while true (>! c (rand)))) >> >> >> >> It doesn't know where/now the channel is consumed (which part of the >> >> point >> >> of channels/queues). However, we do know that at some point, nobody >> >> will >> >> need the result of our producing, so we should stop our activity. >> >> >> >> It seems to me that a natural way to tell the producer to stop is to >> >> close >> >> the channel. However: >> >> >> >> * there's nothing like a clojure.core.async/chan-closed? fn, AFAICT >> >> * The >! fn unconditionally returns nil, whether the channel is open or >> >> not. Only the blocking nature of the call can potentially vary - which >> >> is >> >> not particularly useful for the purpose. >> >> >> >> What would be an adequate way to indicate termination? Just telling the >> >> producer to stop (e.g. (reset! keep-producing false)) would break the >> >> indirection one gains by using channels. >> >> >> >> What if >! returned true/false depending on whether the value was put >> >> (because the channel was open)? >> > >> > -- >> > -- >> > 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. >> >> > > > > -- > “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 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.
