Hi Robert, >From the article: """To bound more the problem, in my case, you control the writers but not the readers"""
So what I was trying to do was to be able to close, with mutiple writers, while being transparent for the readers. The readers only need to read as usual form the channel. For example, if you want to write a library where the user just reads from a channel, this is an approach I found where the user of the lirbary deos nto have to do anything special. Of course, there might be another solution, but if you need to modify the reader we are talking about a different problem. Cheers!! On Wednesday, August 28, 2019 at 7:17:24 PM UTC+2, Robert Engels wrote: > > A better solution is to wrap the writes using a RWLock, grab the read lock > for writing, and the Write lock for closing. Pretty simple. > > Just encapsulate it all in a MultiWriterChannel struct - generics would > help here :) > > -----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/405013db-74c9-474b-857c-09d3f30030c1%40googlegroups.com.
