You can do that without a pub, the producer can send a new (chan) inside the request to the go-loop and the go-loop will ack on that chan when getting a good response from the external service. That schema solves this scenario, I mentioned it in the previous mail, but I think a peek operation maybe could be better and can simplify the producer code.
Saludos, Nahuel Greco. On Sun, Oct 5, 2014 at 1:57 PM, <adrian.med...@mail.yu.edu> wrote: > Ah, I think we're on the same page now. I've come across the need for this > recently in some code for a UDP based protocol between a multiplayer game > client and server. > > I still think a pub fits in here nicely. You can consume the value from > the channel in question and park until you get an acknowledgment from the > external service (or timeout). The producer would subscribe to another > topic on your pub that will get a value put onto it when acknowledgment or > time out occurs in the consumer. Be sure to close the subs after you've > gotten the ack or timed out. > > On Sunday, October 5, 2014 12:40:25 PM UTC-4, 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> 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 >>> 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 > 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. > -- 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.
