Please, drop it. You don't know what you're talking about. I've been amazed at how patient everyone has been. I think it's time to be more blunt in pointing out you don't understand concurrency and independent events.
On Fri, Oct 4, 2019 at 3:15 PM T L <tapir....@gmail.com> wrote: > > > On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote: >> >> On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) >> T L <tapi...@gmail.com> wrote: >> >> > One priority-order select block is not only cleaner than two >> random-order >> > select blocks, but also more efficient. >> >> It is neither. >> >> 1. It is not cleaner, because you would need to somehow denote >> priorities. >> If you think now about "in written order", you should think of the most >> frequent >> cases that you do not want to have all five, ten, twenty cases be >> serviced >> on order. Not to mention that down the road someone might introduce an >> unnoticeable bug for pure aesthetic reasons. >> >> 2. It is not more efficient, it is less efficient because every select >> operation >> would need at least a "priority comparison" op, or - in general case - a >> sort >> op, because not only two channels can be ready, it may happen that all of >> them will. This would have to run for every select then, unless >> introduced by a "select_with_priorities" keyword. >> >> > select(ordered) { > case <-ctx.Done(): > return ctx.Err() > case out <- v: > } > > is undoubtedly more efficient than > > select(randomized) { > case <-ctx.Done(): > return ctx.Err() > default: > } > select(randomized) { > case <-ctx.Done(): > return ctx.Err() > case out <- v: > } > > Not only one less try-receive operation is saved, > but also is the step 2 described in > https://go101.org/article/channel.html#select-implementation saved. > > > >> 3. Others tried to no avail, I will too in other words: >> >> The select switch is deliberately randomized because language creators >> envisioned that otherwise someone would be "smart" and will use >> ordering to impose a **dependency** where it should not be made. >> >> Channel operations serviced by select are treated as sourced >> from **independent** events. Period. >> >> If your out <-v must be dependent of ctx.Done not being ready you >> must resolve this dependency by other means. Eg. by selecting for it >> in separate select before. >> > > It is not a must. It just tries to select ctx.Done if possible. > In fact, if the two evens are independent with each other, > there is no way to absolutely ensure the must. > > >> >> Hope this helps, >> > > You can read the first comment in this thread for another use case of > priority-order > select block. > > >> >> -- >> Wojciech S. Czarnecki >> << ^oo^ >> OHIR-RIPE >> > -- > 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/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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/CABx2%3DD9NnBkz0jCcXM7x%3D4Ms6rw0L%2BmrWGsknD3_kKM_9mMnzw%40mail.gmail.com.