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.
