I have not used core.async much but I did use Go a fair bit and I concur with what Aaron said.
The missing piece for you Paul is that goblocks\channels are not just a way to do concurrent work, but also a control flow mechanism. What Aaron is saying is that by using channels to control various aspects of your programs control flow, you should not need a "count" to do the same. Much like writing Lisp and learning Clojure requires me to learn new idioms, so does the concept of channels. I found this to be a great resource: http://swtch.com/~rsc/thread/<http://swtch.com/~rsc/thread/#10> It is written by Russ Cox, a googler and contributor to Golang. The scholarly papers and presentation slides mentioned at the bottom are also very good. Hope I could help! On Tuesday, January 21, 2014 11:56:56 AM UTC-5, Paul Viola wrote: > > I think this is all well and good for a particular use of channel. > > So perhaps I am misusing channels?? > > To repeat: in one case I have workers pulling from a channel of *real > work*. For various reasons this channel might get filled rather deeply. > In this case I would want to add additional workers or get a bigger > machine. I was wondering if monitoring the channel for things like average > depth (or 99 percentile) would give me the information I needed. > > I could of course "just skip the channel business, and use a java queue" > is a fine proposal. > > But since the producers of this work are truly asynchronous (attached to > the real world) I thought it best to keep the channel methodology. > > > > > > > On Tue, Jan 21, 2014 at 5:11 AM, Aaron France > <aaron.l...@gmail.com<javascript:> > > wrote: > >> On 21/01/14 14:09, Moritz Ulrich wrote: >> >>> On Tue, Jan 21, 2014 at 9:43 AM, Aaron France >>> <aaron.l...@gmail.com<javascript:>> >>> wrote: >>> >>>> Since channels yield nil when they are devoid of items, surely this is >>>> enough to know when the channel is empty? >>>> >>> That's not correct. Take-Operations block on empty channels. They >>> yield nil when they're closed. You could add a timeout to the take >>> operation to see if no item arrived in a specific time. >>> >>> Much appreciated for the clarification. It's the same in Go. >> >> I can imagine this pattern (take on a possibly closed channel being >> useful) being useful but I'm not convinced knowing the count of channel is >> a safe thing to know/care about. >> >> My $0.02, perhaps Clojure does this differently. >> >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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/zD2jl-bIFXI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+u...@googlegroups.com <javascript:>. >> 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.
