I already showed you - just change it to
Select hi
Default:
Select hi,lo
If lo:
Select hi
Default :
Pass
And enqueue the lo if a hi and lo are read.
That is all that is needed.
> On May 6, 2021, at 10:28 AM, 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
>
>
>
>
>> 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, 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.
>
> --
> 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.
--
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/805047A1-8DEC-4D1E-BA5C-D67AFE770544%40ix.netcom.com.
