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.
