On Sunday, September 1, 2019 at 2:05:49 PM UTC-4, Albert Tedja wrote: > > This is something I ran into a while back, and made a library for it, > though, I prefer not to spam the mailing list. Feel free to send me a dm > and I'll send you a github link if you are interested. >
It would be great if you can share the library here. I'm surely interested. And I think many other gophers also have interests. :) > > On Sunday, September 1, 2019 at 3:02:52 AM UTC-7, T L wrote: >> >> >> >> On Sunday, September 1, 2019 at 4:35:10 AM UTC-4, rog wrote: >>> >>> >>> >>> On Sat, 31 Aug 2019 at 10:02, T L <tapi...@gmail.com> wrote: >>> >>>> >>>> >>>> On Saturday, August 31, 2019 at 4:04:29 AM UTC-4, T L wrote: >>>>> >>>>> >>>>> >>>>> On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote: >>>>>> >>>>>> The reason you're wanting priority select is because you are shutting >>>>>> down the data channel preemptively, but you can wait for an >>>>>> acknowledgement >>>>>> from the run goroutine instead: >>>>>> >>>>>> https://play.golang.org/p/qSWluYy4ifl >>>>>> >>>>>> >>>>> Your solution is clever. The Close method can be called multiple time >>>>> safely. >>>>> Is there such a beautiful solution for multiple senders? >>>>> >>>>> >>>> >>>> Translating a multi-senders problem to a single sender problem is the >>>> only way I can get: >>>> https://play.golang.org/p/dAppUxP96g4 >>>> >>> >>> The answer really depends on what you're actually trying to do. What are >>> the multiple senders? What's the actual problem you're trying to solve? >>> >>> I'd fairly sure you'll be able do what you want without requiring a >>> prioritised select, which is what this thread was about. >>> >>> cheers, >>> rog. >>> >>> >> Yes, there are ways to handle the problem of uncertain number of senders, >> but there are no simple ways. >> A mechanism must be designed to avoid any sender writing to a closed >> channel. >> >> >>> >>>> >>>>> >>>>>> On Wed, 28 Aug 2019 at 18:06, T L <tapi...@gmail.com> wrote: >>>>>> >>>>>>> The old thread: >>>>>>> https://groups.google.com/forum/#!topic/golang-nuts/ZrVIhHCrR9o >>>>>>> >>>>>>> Go channels are flexible, but in practice, I often encountered some >>>>>>> situations in which channel are hard to use. >>>>>>> Given an example: >>>>>>> >>>>>>> import "math/rand" >>>>>>> >>>>>>> type Producer struct { >>>>>>> data chan int >>>>>>> closed chan struct{} >>>>>>> } >>>>>>> >>>>>>> func NewProducer() *Producer { >>>>>>> p := &Producer { >>>>>>> data: make(chan int), >>>>>>> closed: make(chan struct{}), >>>>>>> } >>>>>>> >>>>>>> go p.run() >>>>>>> >>>>>>> return p >>>>>>> } >>>>>>> >>>>>>> func (p *Produce) Stream() chan int { >>>>>>> return p.data >>>>>>> } >>>>>>> >>>>>>> func (p *Producer) run() { >>>>>>> for { >>>>>>> // If non-blocking cases are selected by their appearance >>>>>>> order, >>>>>>> // then the following slect block is a perfect use. >>>>>>> select { >>>>>>> case(0) <-p.closed: return >>>>>>> case p.data <- rand.Int(): >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> func (p *Produce) Clsoe() { >>>>>>> close(p.closed) >>>>>>> close(p.data) >>>>>>> } >>>>>>> >>>>>>> func main() { >>>>>>> p := NewProducer() >>>>>>> for n := p.Stream() { >>>>>>> // use n ... >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> >>>>>>> If the first case in the select block in the above example has a >>>>>>> higher priority than the second one, >>>>>>> then coding will be much happier for the use cases like the above >>>>>>> one. >>>>>>> >>>>>>> In short, the above use case requires: >>>>>>> * for receivers, data streaming end is notified by the close of a >>>>>>> channel. >>>>>>> * for senders, data will never be sent to closed channel. >>>>>>> >>>>>>> But, as Go 1 doesn't support priority select cases, it is much >>>>>>> tedious to implement the code >>>>>>> satisfying the above listed requirements. The final implementation >>>>>>> is often very ugly and inefficient. >>>>>>> >>>>>>> Does anyone else also experience the pain? >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "golang-nuts" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to golan...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/golang-nuts/e3015cd8-c2ec-479e-927d-b9ad762d277e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golan...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/e239c78f-61fc-4238-aa5d-f776cb9aec03%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/31ca8865-53f6-47f5-b783-8e9066bf6e4f%40googlegroups.com.
