Dear clojurians, Like many others here, I'm thrilled by the new core.async and wondering about all the goodies that we will be able to reap from it. Thinking about how it decouples the abstracts "threads" of execution with the concrete implementation thread(s) especially in the context of non-blocking network io[*], it reminded me of transactors in pedestal.
A (the) barrier to entry for using pedestal is that it departs for the established ring simplicity with interceptors. Tim Ewald convincingly argues that this was unavoidable in order to scale to the a number of connections that exceeds the number of available (OS) threads, as can be the case with long polling ans Server Sent Events. And this is also restated in the pedestal interceptor docs [***] However, I was wondering if such goal could not be met now with core.async and ring middlewares working on channels ? Would the performance hit be too large ? [****] Would it be still not flexible enough ? Cheers, B. [*] http://martintrojer.github.io/clojure/2013/07/07/coreasync-and-blocking-io/ [**] http://thinkrelevance.com/blog/2013/03/18/pedestal-podcast-episode-027 @ 15' [***] http://pedestal.io/documentation/service-interceptors/ [****] http://programming-puzzler.blogspot.fr/2013/07/stackless-clojure-with-coreasync_7.html -- -- 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.
