On Saturday, August 31, 2019 at 2:32:26 AM UTC-4, rog wrote:
>
> The reason you're wanting priority select is because you are shutting down 
> the data channel preemptively, but you can wait for an acknowledgement from 
> the run goroutine instead:
>
> https://play.golang.org/p/qSWluYy4ifl
>
>
Your solution is clever. The Close method can be called multiple time 
safely.
Is there such a beautiful solution for multiple senders?
 

>
> On Wed, 28 Aug 2019 at 18:06, T L <tapi...@gmail.com <javascript:>> 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/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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/15b4b573-ee9c-4552-be78-84b303173ad7%40googlegroups.com.

Reply via email to