FWIW after all this discussion I *am* curious about a more detailed argument for why we can't have a priority select that guarantees that *if* the high-priority case becomes ready before the low-priority one (in the sense of "there exists a happens-before edge according to the memory model"), the high-priority will always be chosen.
That is, in the example I posted above <https://play.golang.org/p/UUA7nRFdyJE>, we *do* know that `hi` becoming readable happens-before `lo` becoming readable, so a true prioritized select would always choose `hi` and never return. The construct we presented *does* return. Now, I do 100% agree that it's not possible to have a select that guarantees that `hi` will be read if both *become readable concurrently*. But I don't see a *fundamental* issue with having a select that always chooses `hi` if `*hi` becoming readable happens-before `lo` becoming readable*. And to be clear, I also kinda like that we don't have that - I think the value provided by the pseudo-random choice in preventing starvation is worth not having an "ideal" priority select construct in the language. But I couldn't really make a good case why we *can't* have it. -- 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/CAEkBMfGZnPpAiZUvxgibao_n_4M2A%3Dp0cRv5soVXc%2Bqu3BraCQ%40mail.gmail.com.
