Re: [go-nuts] An old problem: lack of priority select cases

[Robert Engels]

I will write and post this evening. 

-----Original Message-----
From: T L
Sent: Aug 28, 2019 1:11 PM
To: golang-nuts
Subject: Re: [go-nuts] An old problem: lack of priority select cases

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.

-- 

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.

--
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/e8e6ceff-1a3e-4c69-93cc-4f5013a3e3c3%40googlegroups.com.

--
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.

--
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/666703422.8714.1567021482476%40wamui-bison.atl.sa.earthlink.net.