Yes, but the advantage of using a pub is that it's simpler to have one input channel than to continually spawning new ones. But that's just my opinion. Anyway, sorry I couldn't be more help.
On Sunday, October 5, 2014 1:04:58 PM UTC-4, Nahuel Greco wrote: > > 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...@mail.yu.edu <javascript:>> > 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 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.
