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 <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.
