I think you should go for the ack solution. What is your reservation about it?
On Sunday, 5 October 2014, Leon Grapenthin <grapenthinl...@gmail.com> wrote: > > > On Sunday, October 5, 2014 5:33:16 PM UTC+2, Nahuel Greco wrote: >> >> Picture the following: >> >> producer ---> go-loop ---> external service >> >> 1- The producer puts a value to a unbuffered (chan) by doing (>! c v) >> 2- The go-loop consumes the value with a take operation, **unblocking** >> the producer >> 3- The go-loop contacts the external-service but the external service >> answers it can't process the value yet >> 4- The go-loop waits some timeout to retry the request to the external >> service >> >> After step 2 the producer continues to compute (suppose an expensive >> computing) a new value but the previous one wasn't effectively consumed by >> the external service. >> I don't want that, I want to enforce an end-to-end flow-control setup >> where the producer blocks on (>! c v) (the step 1) until the value is >> consumed by all parties, >> > > If producing the next value is expensive, why would you want to delay it > from point 2 to after point 4? Once the external service has processed the > current value, you want the next value available as soon as possible, > wouldn't you? > > >> Sure, this flow control can be solved adding an ack channel and sending >> an ack from the go-loop to the producer when the external service >> effectively consumes the value, previously blocking the producer after step >> 1 waiting that ack. >> But I think a peek operation in step 2 will be more elegant. Also, I was >> curious if the implementation of core.async channels limits in some way >> adding a peek operation. >> >> A take-if with a pure predicate can't solve this, because you need to >> contact the external service to decide to consume the value or not. >> >> >> Saludos, >> Nahuel Greco. >> >> On Sun, Oct 5, 2014 at 9:52 AM, Fluid Dynamics <a209...@trbvm.com> wrote: >> >>> On Sunday, October 5, 2014 12:51:04 AM UTC-4, Nahuel Greco wrote: >>>> >>>> I was thinking in a single-consumer scenario with a buffered chan, in >>>> which you want to check if you can consume the value before effectively >>>> consuming it. As you said, a peek operation has no sense if the channel has >>>> multiple consumers. >>>> >>> >>> And if you can't consume the value, then what? Nothing ever does, and >>> that channel becomes useless? >>> >>> Actually the only "peek" operation that to me makes much sense would be >>> a (take-if pred chan) or something similar, which atomically tests the next >>> value with pred and consumes it or not, so, it can't be consumed elsewhere >>> between the pred test and optional consumption here. And if not consumed, >>> two behaviors both occur to me as possible -- return nil or some other >>> sentinel value for "do not want" or block until the unwanted object is >>> consumed by someone else and then test the next item, etc.; at which point >>> you've got four versions of take-if you'd want, the inside-go and >>> outside-go versions cross product with the two when-not-wanted behaviors. >>> >>> At that point, you'd probably be better off just writing a consumer that >>> splits off the pred-matching items into one out channel and feeds >>> everything else into a second channel, with your original consumer taking >>> from the first of these and the others taking from the second. That gets >>> you the block until version of the behavior. The other version can be had >>> by making the pred-using consumer the sole consumer of the in channel, >>> which takes a value, applies pred, and branches, on the "want" branch doing >>> whatever and on the "do not want" branch putting the value onto an out >>> channel that feeds the other consumers before taking its own "do not want" >>> actions. >>> >>> -- >>> 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 >>> 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 >>> 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. >>> 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 clojure@googlegroups.com > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>. > 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 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.
