I understand what you are saying, but all of these situations are basically
race conditions, aren’t they? So there is no deterministic manner of resolving
them. Thus it doesn’t matter which is chosen. However, in the more general,
non-race, condition I believe that it meets the goals.
John
John Souvestre - New Orleans LA
From: Axel Wagner [mailto:axel.wagner...@googlemail.com]
Sent: 2017 January 25, Wed 13:19
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
Doesn't work. If no communication can proceed when entering the select, this
degenerates to a simple select. For example, say there are no writers to any of
those channels. At the same time, that the last select is entered, three
different goroutines start blocking to write to one of the channels each. Even
though priorityHigh could proceed, you will read from one of the other with ⅔
probability.
(a simpler case: Imagine that, while the goroutine is blocking in the innermost
select, a second goroutines enters *the same* select, just with writes.
Semantically, all three communications can proceed at the same time for both
goroutines, so one is chosen uniformly)
This is the fundamental problem with all the nested select solutions; they
assume that the code is evaluated atomically. But in reality, the state of a
communication being possible can change at any point for an arbitrary number of
channels. Thus, you can always construct a sequence where you revert to the
innermost select, violating c.
--
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.
For more options, visit https://groups.google.com/d/optout.
