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.
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.
> 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, 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/CAEkBMfHv2cKR1OLS97YN7JYKZXHu_s0a-6c0-2tW%3DS0gUU8jUA%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/CAEkBMfHQq2p60OenLMYUFz%3DK9HigpbAqj7m%3D%2BRp7BnCX%2Bp1QLA%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/C2214C2E-8D44-409A-8E29-4665E941E86C%40ix.netcom.com.
