But notice that each of these  examples uses either uses multiple channels.
Or is unrecommended behavior.

In your latter example, you're throwing parallelism out of the window. It
might work better if you had something like (go (f x)) but that then
creates an unbounded queue. Why not allow subscribers to hand a channel
instead of a function? That way your system is uniform and back-pressure
would work as expected. In addition, subscribers to could pass in buffered
or sliding-buffered channels and this would allow slower consumers to not
hold up the entire system.


On Fri, Jul 19, 2013 at 7:03 AM, Cedric Greevey <cgree...@gmail.com> wrote:

> On Fri, Jul 19, 2013 at 8:25 AM, Timothy Baldridge 
> <tbaldri...@gmail.com>wrote:
>
>> channels - allow multiple producers to provide data to multiple consumers
>> on a one-to-one basis. That is to say, a single value put into a channel
>> can only be taken by a single consumer.
>>
>
> Although, you can implement a "cable splitter", e.g.
>
> (go
>   (loop []
>     (let [x (<! c1)]
>       (>! c2 x)
>       (>! c3 x))
>     (recur)))
>
> if you need to send some stuff to multiple consumers. Or even implement a
> subscription service:
>
> (def submap (atom {}))
>
> (defn subscribe [c f]
>   (swap! submap #(merge-with into % {c #{f}})))
>
> (defn unsubscribe [c f]
>   (swap! submap #(let [s (disj (% c) f)]
>                     (if (empty? s)
>                       (dissoc % c)
>                       (assoc % c s))))
>
> (defn submit-channel [c]
>   (go
>     (loop []
>       (let [x (<! c)]
>         (doseq [f (@submap c)]
>           (f x)))
>       (recur))))
>
> or something like that (untested, but subscribing a function to a
> submitted channel should result in it getting called with each item put
> onto the channel until it's unsubscribed or the producer stops putting
> things onto it; replacing the callbacks with channels that will get copies
> put onto them while subscribed should be a trivial transformation).
>
>  --
> --
> 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.
>
>
>



-- 
“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/groups/opt_out.


Reply via email to