> > > >> Secondly, I've perhaps mistakenly considered channels more as a conduit >> between processes rather than a replacement for single assignment message >> passing. I get the value of using a channel and the core.async state >> machine for achieving promise-like semantics in a non-blocking way, and I >> can achieve that for a single consumer with a normal channel, the rub is >> this new buffer allows repeated consumption of a single value, and my >> previous understanding of channel semantics 'a channel will return nil when >> it is closed after some number of takes' no longer holds in all cases, >> because a promise-buffer is never exhausted. >> > > Nothing about channels guarantees they will be closed after some number of > takes, so I disagree with this definition. >
To be clear, I didn't mean that a channel is guaranteed to be closed, rather that previously I could count on the ability to drain a channel after I have chosen to close it. Closing a promise-chan which has received a value has no impact on later takes, it is indistinguishable from a channel with an infinite buffer filled with a single value, which feels like a deviation from the thought that unbounded buffers are bad. The example in my previous message will OOM when used with a promise-chan. This new behaviour doesn't directly contradict the close! dosctring - "Data in the channel remains available for taking, until exhausted, after which takes will return nil", but that description could leave you with the expectation that data is exhausted. I guess I'm trying to understand if this new channel type is intended to be used with the battery of existing channel macros (pipe, reduce, pipeline, mult, etc.), where it may act as an unbounded, uncloseable producer of values, or if it's really only intended to be used as a promise which can be resolved in a non-blocking manner using put, take, >!, <!, !!>, !!<. If it's the latter, would it make sense to rename promise-chan to promise, i.e. a core.async promise type who's implementation happens to be a channel, and expand only those macros relating to puts and takes to accept chan-or-promise. Thanks again. -- 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.
