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 <javascript:>.
> 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e8e6ceff-1a3e-4c69-93cc-4f5013a3e3c3%40googlegroups.com.
