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