A big reason they have to be run inside the lock is that they have to operate in the context of the channel.
For example: (chan (take 10)) Firstly we must recognize that transducer instances are *not* thread safe. They should only ever be executed by one thread at a time. But channels allow multiple puts and takes. Also channels are not processes, they are simply rather complex lists with locks around them. This means, if you want to execute take correctly you must ensure that only one thread executes the take instance at one time, since channels already operate via a channel-level lock, it makes sense to run the transducer inside the channels' lock. But that's also why it's always been recommended to stick with simple, non cpu-intensive, non blocking operations in channel transducers. Timothy On Mon, Jul 3, 2017 at 4:30 PM, Kevin Downey <redc...@gmail.com> wrote: > On 07/03/2017 03:12 PM, Vitalie Spinu wrote: > >> >> >> >> On Monday, 3 July 2017 22:48:40 UTC+2, red...@gmail.com wrote: >> >> >> Discussion of locks aside, doing blocking operations like io or <!! or >> >!! or basically anything that looks like it blocks and isn't >! >> or <! >> is a very bad idea in a transducer on a channel. You will (eventually) >> block the threadpool and get deadlocks. >> >> >> >> Is this the limitation in general or only when I use the chan with >> blocking transducer withing a go block? Transducers are not run on a go >> block, are they? >> >> > It is kind of complicated, and I haven't traced through everything in > channels.clj recently, but assume transducers are not magic, the > computation has to occur on some real thread some where, and the best > threads available to do that are the consumer thread and the producer > thread. If those threads are both executing go blocks, and you have a > transducer doing blocking stuff on a channel they operate on, you may not > be technically "blocking" in the go block, but the channel machinery is now > blocking before it yields control back to the go block. Putting blocking > operations in a transducer then operating on the channel from go blocks > turns `!>` and '<!' from operations that don't block threads (just park go > blocks), in to operations that do block a whole OS thread, of which the > core.async threadpool that go blocks execute on only has 8 by default. > > There is this sort of dance where control is handed back and forth between > channels and go blocks without tying up a thread. When you introduce > blocking in to the channel machinery (by making the channel execute a > blocking operation as things are produced or consumed) then the dance stops > and the thread waits. > > -- >> 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 <mailto: >> clojure+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > And what is good, Phaedrus, > And what is not good— > Need we ask anyone to tell us these things? > > -- > 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. > -- “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.
