PS: And I'm not saying there is no argument. Maybe "select is not atomic" is such an argument. But if there is an argument and/or if this is that argument, I don't fully understand it myself.
On Thu, May 6, 2021 at 3:40 PM Axel Wagner <axel.wagner...@googlemail.com> wrote: > 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/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.com.
