To clarify again: As a litmus test, a `select` construct like the one I'm
talking about would mean that this code blocks forever:
https://play.golang.org/p/LcWgDcX5ojl
With the current `select`, it doesn't. With a different `select`, which
uses source order to express priority and under the semantics I'm asking
about, this would always block, because `lo` would never be read.
On Thu, May 6, 2021 at 10:05 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
>
>
> On Thu, May 6, 2021 at 9:40 PM Robert Engels <reng...@ix.netcom.com>
> wrote:
>
>> But that is not really true because there are no constraints on if the
>> source channels are buffered - if they are then my code operates similarly.
>>
>
> I was very clear. I was asking if it is possible to implement a priority
> select with the semantics "if the high priority case becomes ready before
> the low priority case, it always takes the high priority case". Saying "but
> what if we try to ensure that both of them are always ready" is not
> answering the question.
> Please stop insisting that the code you provide solves this. It simply
> doesn't. Given that I phrased the question, I feel justified in claiming
> the authority if it does or not.
>
>
>> Even if using unbuffered channels there is buffering being done at a
>> lower level (hardware buffers, network stack buffers, etc) - so not
>> “unblocking a sender” is a dubious endeavor.
>>
>
> That is how select behaves, though. It chooses a communication to proceed
> (currently, uniformly at random, under the premise of the question, the
> highest priority one) and lets that proceed.
>
> If you don't have an answer to the question I posed, it is okay to just
> not answer it. If there is no answer, that's okay too. But arguing about
> code which clearly does not answer it is frustrating.
>
>
>>
>>
>
>> On May 6, 2021, at 1:30 PM, 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>
>> On Thu, May 6, 2021 at 8:22 PM Robert Engels <reng...@ix.netcom.com>
>> wrote:
>>
>>> “If lo” means that if the lo channel was read.
>>>
>>
>> Exactly. To fulfill the requirements and answering the question, it must
>> not be read.
>>
>> This code will prevent a lo from being processed if a hi is available at
>>> the happens before moment of a value being ready.
>>>
>>
>> What the receiver does with the value is immaterial. Point is, that the
>> receiver has already read the value, thus the communication has happened,
>> thus the sender was unblocked. The question is about a select that wouldn't
>> do that.
>>
>>
>>> Btw using indents rather than brackets in the above - maybe that is
>>> causing the confusion.
>>>
>>
>> I'm not confused. Your code is simply not answering the question posed.
>> Which is about a select which always lets the high priority communication
>> happen, if it is ready before the low priority communication - and
>> consequently *doesn't* let the low priority communication happen.
>>
>>
>>>
>>>
>>>
>>> On May 6, 2021, at 12:37 PM, 'Axel Wagner' via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
>>>
>>> No, it is not. Your "if lo" branch implies that the communication
>>> happened - e.g. the sender was already unblocked. A `select` would not
>>> unblock the other side unless that's the actual branch taken.
>>>
>>> On Thu, May 6, 2021 at 7:32 PM Robert Engels <reng...@ix.netcom.com>
>>> wrote:
>>>
>>>> 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
>>>>>>> <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
>>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHEEDdL8adBDFoqwVHswK3kr_KawePGi%3DNtbaBVTP5KWw%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/CAEkBMfHv2cKR1OLS97YN7JYKZXHu_s0a-6c0-2tW%3DS0gUU8jUA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHv2cKR1OLS97YN7JYKZXHu_s0a-6c0-2tW%3DS0gUU8jUA%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/CAEkBMfHQq2p60OenLMYUFz%3DK9HigpbAqj7m%3D%2BRp7BnCX%2Bp1QLA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHQq2p60OenLMYUFz%3DK9HigpbAqj7m%3D%2BRp7BnCX%2Bp1QLA%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/CAEkBMfHL_G5bGs6tGXO6U8H%3DYMNf6f3%2B4V1JDxALEfOpGhQjvA%40mail.gmail.com.
