Re: core.async count in a channel

On Jan 21, 2014, at 11:56 AM, 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 rat

Re: core.async count in a channel

Hello Paul, Why not just adjust the number of workers based on actual workload instead of monitoring the source channel for average depth ? Have a look at this codefrom clojure

Re: core.async count in a channel

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

Re: core.async count in a channel

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

Re: core.async count in a channel

On 21/01/14 14:09, Moritz Ulrich wrote: On Tue, Jan 21, 2014 at 9:43 AM, Aaron France 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'r

Re: core.async count in a channel

On Tue, Jan 21, 2014 at 9:43 AM, Aaron France 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 th

Re: core.async count in a channel

Hi, Whilst I am pretty new to clojure. I am not to Go. The counting of items in a channel is usually regarded as an error and a race condition causing idea. Since channels yield nil when they are devoid of items, surely this is enough to know when the channel is empty? Aaron -- -- You recei

Re: core.async count in a channel

@Meikel, I like your solution. Its key advantage is that you have enable arbitrary functionality in the "monitoring" of a channel. Since I am new to Clojure, and I bet others are too, I was subconsciously thinking about creating a new kind of channel (monitored channel). This solution does s

Re: core.async count in a channel

@Meikel: I am now convinced that you are right. It's clear to me that I completely underestimated the power / flexibility of the Channel abastraction. @World: I now retract my second-ing of "adding count to Protocol of Channel" On Fri, Jan 17, 2014 at 2:10 AM, Meikel Brandmeyer (kotarak) wrote:

Re: core.async count in a channel

Hi again, and some more golfing by Christophe: (defn queue-process-uncontrolled [input output stats] (async/go (loop [q clojure.lang.PersistentQueue/EMPTY] (let [[val-to-q ch] (async/alts! (if-let [v (peek q)] [input [output

Re: core.async count in a channel

Bleh when you see the bug as you hit "Send" (defn queue-process [input output stats] (async/go ; Wait for the first input. (loop [v (async/ Empty queue. (identical? ch input) (recur nil (cons v q)) ; Write happened, and there is more in the queue.

Re: core.async count in a channel

Hi, the average channel has no queue. Processes freeze until the peer process arrives. So count doesn't make sense for the typical channel. If you want to implement a queue, you could create a process which accepts values on end and distributes to the other. Then you can keep also track of any

Re: core.async count in a channel

I second the request to add a "count" field to the channel protocol. I also agree that having to keep track of the buffer just to get the count is hacky-ish. On Thu, Jan 16, 2014 at 3:29 PM, Paul Viola wrote: > > Still finding my way around Clojure... sorry if this is trivial. > > I am using c

core.async count in a channel

Still finding my way around Clojure... sorry if this is trivial. I am using core.async to implement a queue for a collection of workers that pull jobs and complete them (there may be multiple producers as well). All looks great so far. Except when it comes time to close down the pipe (and dr