To be honest, I don't see any contradiction here. You can bring everything back easily:
1. Just take existing core.async channels as is 2. Replace callback based take! and put! with promise based take! and put! 3. That's it! Instead (<! channel) (>! channel val) you do (<! (take! channel)) (<! (put channel val)). You can also provide some convenience macroses. The whole point of this topic is that, it seems you often need just a go block, but core.async always wraps it with channels and unnecessary async guarantees. вторник, 11 марта 2014 г., 22:58:19 UTC+4 пользователь tbc++ написал: > > You can take the CSP out of core.async, but then it really isn't the same > thing. Your version with promises still allows for async, but in the > process removes most of the benefits of CSP. > > Timothy Baldridge > > > On Tue, Mar 11, 2014 at 12:29 PM, Ben Mabey <b...@benmabey.com<javascript:> > > wrote: > >> I've also ran into situations as well where the context switching of >> the thread pool is prohibitive. I swapped out the thread pool with a single >> threaded executor and saw a big speed improvement. The downside is that >> you can not specify what thread pool a go block should be ran on. This >> means I had to hack the global thread pool like so: >> >> ;; hack for using a single thread >> (in-ns 'clojure.core.async.impl.exec.threadpool) >> >> (defonce thread-factory (conc/counted-thread-factory >> "clj-sim-dispatch-%d" false)) >> >> (defn sim-executor [] >> (Executors/newFixedThreadPool 1 thread-factory)) >> >> (defonce single-tp (sim-executor)) >> (def the-executor single-tp) >> >> (in-ns 'my-ns) >> >> I'd be curious to see if this hack gives you similar performance benefits >> as your promise fork. It would be nice if you could pass in an executor to >> a go-block to override the default global one to accommodate these >> different use cases. This would be similar to how you can now control the >> executors for futures. >> >> -Ben >> >> >> On 3/11/14, 11:39 AM, Эльдар Габдуллин wrote: >> >> Each go block is executed via thread pool. On a channel side, producers >> and consumers are also decoupled. >> Such decoupling costs around 10-20 us per async operation. For the cases >> when your async >> values are immediately available (e.g. from cache), or when you designed >> an async >> API just because your operations may block for a long but not necessary >> do, those are huge numbers. >> >> For example, I recently worked on a dependency injection >> container<https://github.com/dar-clojure/core> which >> supports async computations. >> Asynchrony in one place means that all you API will be async everywhere. >> Natural way to go with implementation is to just >> wrap everything in a go block. However, after doing that I found that >> container became 50 times slower. 5 us overhead for a >> typical task turned into 250 us. >> >> As a solution I forked <https://github.com/dar-clojure/async> core.async >> and replaced channels with lightweight promises and removed thread pool >> dispatch from >> everywhere. Now async container implementation is only 5 times slower >> than its sync version, which is probably acceptable. >> >> I'd like to hear what others think about this issue, especially members >> of the core team. >> >> -- >> 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. >> >> >> -- >> 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.
