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.
