go blocks, together with >!, <!, alt!, etc... do not create any new threads and are not run in separate thread. There is no thread pool for go blocks. Code inside go blocks is transformed into state machine, and the state machine 'object' is parked in the corresponding channel. When the complementary operation on the channel is invoked (e.g. put is parked and take is later invoked), the state machine resumes and produces/consumes value. It can all happen in the one thread.
If your code results in handful of long running threads, I would go with threads and >!! <!!. If you need arbitrary number of 'threads' or if they are short lived, go blocks is the way. JW On Thu, Jan 30, 2014 at 7:22 PM, Caspar Hasenclever <casp...@nonplacet.net>wrote: > I think your case is exactly where not to use go blocks. Stuff in go > blocks is executed on a limited size thread pool so with enough blocking > I/O in there you could in theory slow down async processing. > > The win in using <! and >! in go blocks is that they don't block async > threads _while they are waiting for input/output channels_. Once you > have a value from <! anything you do with it is run on one of the async > threads and can therefore block those. If you do this in enough places, > thus blocking enough threads from the async thread pool, you could slow > down the whole thing. > > If you already know that you are performing blocking I/O, I would stick > to running those functions with async/thread or just simple future > (since you are not using the output channel returned by async/thread). I > have used just futures in a context similar to yours (piping data in and > out of dbs) and used the channels as just that: pipes (and used go blocks > for CPU-bound functions or for plain routing values through channels). > > Of course if you only have a handful of threads as in your example, the > difference won't be that great :) > > HTH, > > Caspar > > P.S. a side note on your code: you might want to terminate your loops > when the channel is closed, rather than using (while true ...). You will > get endless nils from a closed channel, probably not what you want to > keep processing. > > -- > 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. > -- 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.
