On Wednesday, August 28, 2019 at 1:49:51 PM UTC-4, Robert Engels wrote: > > As I said in another email, using a RWMutex makes the multiple senders > problem easily solvable. Grab the Read lock when writing, and the Write > lock when closing. Set a 'closed' flag during Close that is checked during > the write. >
Could you show a piece of code for easily understanding? > > -----Original Message----- > From: T L > Sent: Aug 28, 2019 12:37 PM > To: golang-nuts > Subject: Re: [go-nuts] An old problem: lack of priority select cases > > > > On Wednesday, August 28, 2019 at 1:12:10 PM UTC-4, Robert Engels wrote: >> >> And what I was trying to say is that request is inherently racy. >> >> You can already do priority selects. see >> https://play.golang.org/p/58FfsKIivSr as a way to do it - more realistic >> though to use buffered channels. Pretty easy to wrap this in a function >> that takes N channels. >> > > This is not the priority I expected. Could you make an example based on my > code in the first comment? so that I can understand it easily. > In fact, I have verbose version which doesn't need priority select cases. > It is an acceptable solution. But there are many other more complex cases, > such as multiple senders. > I haven't found an acceptable solution for such complex cases. > > import "math/rand" > > type Producer struct { > data chan int > closing chan struct{} > canSafeClose chan struct{} > } > > func NewProducer() *Producer { > p := &Producer { > data: make(chan int), > closing: make(chan struct{}), > canSafeClose: make(chan struct{}), > } > > go p.run() > > return p > } > > func (p *Produce) Stream() chan int { > return p.data > } > > func (p *Producer) run() { > for { > select { > case <-p.closing: > close(p.canSafeClose) > return > default: > } > > select { > case <-p.closing: > close(p.canSafeClose) > return > case p.data <- rand.Int(): > } > } > } > > func (p *Producer) Close() { > close(p.closed) > <-p.canSafeClose > close(p.data) > } > > func main() { > p := NewProducer() > for n := p.Stream() { > // use n ... > } > } > > >> -----Original Message----- >> From: T L >> Sent: Aug 28, 2019 11:43 AM >> To: golang-nuts >> Subject: Re: [go-nuts] An old problem: lack of priority select cases >> >> >> >> On Wednesday, August 28, 2019 at 12:36:56 PM UTC-4, Robert Engels wrote: >>> >>> That's inherently racy - since between when the runtime determines the >>> channel is OK for writing, another routine can close the channel before the >>> write is attempted - so "priorities" won't help. >>> >> >> I understand this. What I mean is it would be great to support priority >> select cases. >> >>> >>> -----Original Message----- >>> From: T L >>> Sent: Aug 28, 2019 11:06 AM >>> To: golang-nuts >>> Subject: [go-nuts] An old problem: lack of priority select cases >>> >>> 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/0f753567-eaa8-4d1d-9db1-a3f382f59216%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/0f753567-eaa8-4d1d-9db1-a3f382f59216%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 <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/e8e6ceff-1a3e-4c69-93cc-4f5013a3e3c3%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/e8e6ceff-1a3e-4c69-93cc-4f5013a3e3c3%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/2f9acd65-682a-45e1-bdd8-ba4036792d68%40googlegroups.com.
