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 

Reply via email to