Hey, this looks very interesting. However I'm a little concerned about the semantics of >! and <!.
https://gist.github.com/thheller/5890363 (ns thheller.async-test (:use clojure.test) (:require [clojure.core.async :as async :refer (go >! <! >!! <!!)])) (def c (async/chan)) (defn do-some-work [work] (throw (ex-info "no way" {:work work}))) (go (loop [work-done 0] (let [[reply-to work] (<! c) reply (do-some-work work)] (>! reply-to reply) (recur (inc work-done)) ))) (let [me (async/chan)] (>!! c [me :work-work]) (<!! me) ;; never returns ) The go-thread dies on the first message and never replies, the other thread waiting for a reply (be it the current thread as in my example, or another go-thread) will now be stuck. Thus I need an extra timeout for EVERY <! I ever do, you hinted as much in your blog post. Waiting for messages that never arrive. However you may also run into situations where >! never returns, cause the consumer died and the buffer is full. How do you "return" from that? Can I do alt! (timeout) on a put? Or does a full buffer throw? >From what I understand one can "<!" the result of the outer (go ...) to detect that it in fact "ended"? I guess there could be some helper functions which restart go-threads in case of accidental deaths. Although right now an exception does not seem to close the go result channel. I still prefer Erlang (Actors) since it seems way easier to reason about and process links and monitors (supervisors) certainly make failures alot easier to detect/handle. Any words on the state of the CLJS port? Looking through the code I found that setTimeout(fn, 0) is used alot. HTML5 Spec [1,2,3] says "If the currently running task is a task that was created by the setTimeout() method, and timeout is less than 4, then increase timeout to 4." That may cause some trouble, thought I mention this. Anyways, its pretty nice piece of work and I will certainly play with it for a while. Cheers, /thomas [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#timers [2] https://developer.mozilla.org/en-US/docs/Web/API/window.setTimeout#Minimum.2F_maximum_delay_and_timeout_nesting [3] http://dbaron.org/log/20100309-faster-timeouts On Friday, June 28, 2013 9:06:47 PM UTC+2, Rich Hickey wrote: > > I've blogged a bit about the new core.async library: > > http://clojure.com/blog/2013/06/28/clojure-core-async-channels.html > > Please try it out. > > Thanks, > > Rich > > -- -- 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.
