On Sunday, October 5, 2014 10:14:19 PM UTC+2, Nahuel Greco wrote: > > Maybe not, maybe you want to reserve the cpu cycles for other tasks, or > the producer needs a confirmation for other purposes before computing or > requesting the value from another party. This is a simplified and distilled > scenario. > If you only want to begin to produce the next value after the current has been consumed by the external service I doubt that core.async has any use: A perfectly fitting solution can be described as a completely synchronous procedure where none of the steps are supposed to overlap in time:
1. Request value from other party, wait for it or compute it 2. Wait for external service to be ready 3. Send value to external service, discard value 4. Go to 1 > El 05/10/2014 16:55, "Leon Grapenthin" <grapent...@gmail.com <javascript:>> > escribió: > >> >> >> 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 clo...@googlegroups.com >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> 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.
