On Wednesday, August 28, 2019 at 1:14:09 PM UTC-4, Robert Engels wrote: > > Reading the article, why not just wrap the write function in one that uses > panic/recover, since the write is expected to panic if the channel is > closed. >
Using panic/recover is a way, but it is ugly. > > -----Original Message----- > From: Leo Lara > Sent: Aug 28, 2019 11:24 AM > To: golang-nuts > Subject: [go-nuts] Re: An old problem: lack of priority select cases > > This is connected with my article: > https://dev.to/leolara/closing-a-go-channel-written-by-several-goroutines-52j2 > > I think there I show it is possible to workaround that limitation using > standard Go tools. Of course, the code would be simple with priority > select, but also perhaps select would become less efficient. > > On Wednesday, August 28, 2019 at 6:06:33 PM UTC+2, T L 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 <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/b284f880-034a-4721-8686-ef48d3e2c14c%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/f6c8e515-525e-4f3c-b384-70e510b687d5%40googlegroups.com.
