You still are not understanding proper concurrent design. Priority select
cases do not matter in the case of asynchronous external events.
> On Oct 4, 2019, at 1:46 PM, T L <tapir....@gmail.com> wrote:
>
>
> I just found an example in the "context" package docs:
>
> // // Stream generates values with DoSomething and sends them to out
> // // until DoSomething returns an error or ctx.Done is closed.
> // func Stream(ctx context.Context, out chan<- Value) error {
> // for {
> // v, err := DoSomething(ctx)
> // if err != nil {
> // return err
> // }
> // select {
> // case <-ctx.Done():
> // return ctx.Err()
> // case out <- v:
> // }
> // }
> // }
>
> It looks the send "out <- v" still has a possibility to be executed,
> even if "ctx.Done()" is closed.
> But if Go supports select case priority, then this will never happen.
>
>
>> On Wednesday, August 28, 2019 at 12:06:33 PM UTC-4, 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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/b7a14153-253e-43c4-bda5-96079601465f%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/5DB82954-56D2-455F-ADF4-02B845D52783%40ix.netcom.com.
