code-reviews

2015-07-10T18:26:44.000732Z

Hey all, I'm trying to write my first transducer. I'm processing an endless channel of data and would like to simple do something every n elements processed. Does this look right?

(defn do-every
  "Returns a transducer that executes f every n steps."
  [n f]
  (fn [rf]
    (let [i (volatile! 0)]
      (fn
        ([] (rf))
        ([result] (rf result))
        ([result input]
         (when (zero? (mod (vswap! i inc) n))
           (f))
         (rf result input))))))
I copied the volatile! from an example on http://clojure.org/transducers, but, I admit, I'm not entirely sure what it does...

alejandro 2015-07-10T20:15:35.000735Z

@devon: have you tried partition-all?

alejandro 2015-07-10T20:16:26.000736Z

I may have misunderstood, were you just trying to implement similar behavior?

alejandro 2015-07-10T20:17:32.000737Z

nvm, it’s just side-effecting f with no args

alejandro 2015-07-10T20:19:04.000738Z

looks reasonable. I think of volatile as an atom that can only be written to from a single thread at a time, but is faster than an atom because of that. If you find good docs explaining its usage, please share!

2015-07-10T20:27:25.000740Z

oh, that makes sense, great to know! thanks!

ghadi 2015-07-10T20:45:19.000741Z

devon: note that channel transducers run inside the internal channel locks, so that should be a quick side-effect

ghadi 2015-07-10T20:45:40.000742Z

not a potentially blocking one

ghadi 2015-07-10T20:46:17.000743Z

if it is not in that category -- probably should run that function not in a transducer

2015-07-10T20:53:05.000744Z

This one is, it's just logging. But, out of curiosity, is it any worse to have a potentially blocking code in transducer on the channel vs something that's consuming off of it? Assuming that it's only one thread is consuming?

ghadi 2015-07-10T20:55:47.000745Z

it is worse because it's easy to forget about it and do it in multiple places in the application and generate surprising deadlocks

ghadi 2015-07-10T20:57:39.000746Z

channel monitoring is on the roadmap, and I'm sure Rich and Stu have thoughts.

2015-07-10T21:21:05.000747Z

great to know, thanks!