Add one more chan, "external ready". Put :ok there to let producer generate new value.
producer: - read from "external ready" - generate value - put into "outgoing" chan client: - contact external server, put in "external ready" if ok - read from "outgoing" chan - send to external Handle exceptions and loop where you need. On Sunday, October 5, 2014 7:40:25 PM UTC+3, Nahuel Greco wrote: > > previous example with the peek operation: > > 1- The producer puts a value to a unbuffered (chan) by doing (>! c v) > 2- The go-loop unparks from (peek<! c) without consuming the value, the > producer keeps parked > 3- The go-loop contacts the external-service > 4-A If the external-service answer is ok, the go-loop consume (and > discard) the value by doing a normal (<! c), and the producer unparks > 4-B If the external-service answers it cannot process the value, the > go-loop waits until a timeout to retry step 3 > > The producer only unparks when the value is effectively consumed by the > external service. That's my objective. > > I think your pub proposal replaces the take-if proposal given before, but > I think take-if (and pub) doesn't work for this scenario. > > > Saludos, > Nahuel Greco. > > On Sun, Oct 5, 2014 at 1:20 PM, <adrian...@mail.yu.edu <javascript:>> > wrote: > >> Then how would peeking at the value help? >> >> On Sunday, October 5, 2014 12:14:32 PM UTC-4, Nahuel Greco wrote: >>> >>> Adrian: I don't see how a pub can help here, in the previous example to >>> consume or not the value was decided not on some property intrinsic to the >>> value (one you can create a topic from), but on the result of sending it to >>> an external service. >>> >>> >>> Saludos, >>> Nahuel Greco. >>> >>> On Sun, Oct 5, 2014 at 12:59 PM, <adrian...@mail.yu.edu> wrote: >>> >>>> I think you can achieve an effect similar to what you want by using a >>>> pub with an appropriate topic function that classifies the input in some >>>> way, and then subscribing to the topic whose value you want to see. This >>>> also has the benefit of automatically 'mult'ing the channel input, so you >>>> can have multiple consumers looking for the same value. >>>> >>>> On Sunday, October 5, 2014 11:33:16 AM UTC-4, 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, >>>>> >>>>> 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 >>>> 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.
