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.
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/f039b189-e59f-4041-b06d-7c20fadd4caa%40googlegroups.com.
