On Thu, May 6, 2021 at 4:43 PM roger peppe <rogpe...@gmail.com> wrote:
>
> On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> 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.
>>
>
> One reason is that the semantics can conflict. Consider this code, for
> example (assuming a hypothetical "pri select" statement that chooses the
> first ready arm of the select) - the priorities conflict. I suspect Occam
> doesn't encounter that issue because it only allows (or at least, it did
> back when I used Occam) select on input, not output. I believe that
> restriction was due to the difficulty of implementing bidirectional select
> between actual distributed hardware processors, but I'm sure Øyvind knows
> better.
>
> func main() {
> c1, c2, c3 := make(chan int), make(chan int), make(chan int)
>
> go func() {
> pri select {
> case c1 <- 1:
> case v := <-c2:
> c3 <- v
> }
> }()
> go func() {
> pri select {
> case c2 <- 2:
> case v := <-c1:
> c3 <- v
> }
> }()
> fmt.Println(<-c3)
> }
>
Interesting case. I would argue, though, that there is no happens-before
edge here to order the cases and I was only considering providing a
guarantee if there is one.
> That said, I suspect that the semantics could be ironed out, and the real
> reason for Go's lack is that it's not actually that useful; that it would
> be one more feature; and that in practice a random choice makes sense
> almost all the time.
>
As I said, this would certainly satisfy me as an answer :)
>
>
> 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
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/CAEkBMfHEEDdL8adBDFoqwVHswK3kr_KawePGi%3DNtbaBVTP5KWw%40mail.gmail.com.
