Thanks for your reply. I just studied the pipeline code and am now wondering how it can affect on which thread the transducer runs if the answer to the question is unspecified.
The blocking put is made on a separate thread (channel named res), then later a blocking take from that same channel is made in the second go-loop. Or are you saying "if it takes too long, parallelize via pipeline"? In my case I can't because the transducer is stateful. I can run multiple pipelines with multiple transducer instances if I split up the inputs manually and later merge the outputs. But since the transducer does all of the relevant work, I need to determine where it runs. The only alternative I see is to re-implement the transducer process within a thread/loop body and run multiple of those. I am not familiar with the JVM locking mechanism of core.async so what should I be worried about when the "transducer is executed inside the channel lock"? Are other channels going to have to wait if it is too slow? On Wednesday, December 16, 2015 at 2:06:24 PM UTC+1, tbc++ wrote: > > When the transducer code was originally added to core.async I asked Rich > this very question. He declined to specify where the transducer is run. The > reasoning is simple: since the transducer is executed inside the channel > lock, your transducers should always be fast enough that you don't care > where they are run. If the transducer is going to take long enough that you > care about where it executes, you should use async/pipeline instead. > > Timothy > > On Wed, Dec 16, 2015 at 4:16 AM, Leon Grapenthin <grapent...@gmail.com > <javascript:>> wrote: > >> Is it safe to say that a transducer in a channel always executes on the >> producer thread? >> >> Kind regards, >> Leon. >> >> -- >> 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 the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- 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/d/optout.
