On Fri, 4 Oct 2019 13:52:19 -0700 (PDT) T L <tapir....@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. 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. Hope this helps, -- 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/20191004233941.0b5c516e%40zuzia.
