I agree with you.
However, with the first select in the example we have a "first" and with
the second we have an "after" which might be considered race condition(s9
for the purpose of seeing the example of what I was after.
Also, scheduling arguments cannot be used here: like "we know that there is
no scheduling (of go goroutines) between the first and the second select."
If we know, it's not an argument.
torsdag 29. april 2021 kl. 14:35:31 UTC+2 skrev axel.wa...@googlemail.com:
> On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig <oyvin...@teigfam.net> wrote:
>
>> Interesting!
>>
>> Your suggestion would in fact do pri select in the special case 1. below:
>>
>> 1. Poll highPri first (take it if it's ready), if highPri not ready
>> then take lowPri (provided highPri has not become ready since the first
>> poll)
>> 2. However, if highPri has become ready between the first and the
>> second, then it would be taken (provided lowPri is not also ready)
>> 3. If both have become ready when the second select is entered they
>> would be taken 50% of the time on the average
>>
>>
> One thing to point out is that since we are talking about concurrency,
> where you can really only talk about something happening "after" something
> else happened, if there is a causal edge between them, this really *is*
> equivalent to a simple priority select. You can't observe the difference,
> unless you add more synchronization - in which case we aren't really
> talking about the code under discussion anymore.
>
> I fail to see that this is the general pri select that I am quering about
>> whether it has "appeared" in go over the last years.
>>
>
> I tend to agree with you on this though. So to answer that question
> plainly: No, there is no prioritized select in Go and I find it personally
> unlikely that we'll get one. It might be possible to address some use cases
> when we get generics, though.
>
>
>> I have a stomach feeling that it can not be implemented by polling. In
>> the semantics of a select the whole select is evaluated before it is
>> entered to se if there is/are any guard(s) ready. If not, pick randomly. If
>> not, set alle guards up in some wait state.
>>
>> The default case I have always used like "since no event ready (polling)
>> then do something else than listening again on the same events". occam has
>> deafult (although it's called TRUE & SKIP), xC does not.
>> torsdag 29. april 2021 kl. 11:36:45 UTC+2 skrev Jan Mercl:
>>
>>> On Thu, Apr 29, 2021 at 11:24 AM Øyvind Teig <oyvin...@teigfam.net>
>>> wrote:
>>>
>>> > This is not solved with a default clause, which transforms the
>>> selective choice waiting for some event to happen into busy polling. It's
>>> nice yo have some times, but that is something orthogonal to pri/ordered.
>>>
>>> Not sure if I would call it busy polling, but I meant schematically
>>> this:
>>>
>>> select {
>>> case x := <-highPriority:
>>> handle(x)
>>> default:
>>> select {
>>> case x := <-highPriority:
>>> handle(x)
>>> case x := <-lowPriority:
>>> handle(x)
>>> }
>>> }
>>>
>> --
>> 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...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/47051a51-f040-4b51-a792-24a0f96c50f4n%40googlegroups.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/cf43611c-599f-46d9-98ac-60ede00daea9n%40googlegroups.com.
