It is trivial to do a priority select. Check the high priority channel again
after getting a low priority value. If the high priority is available enqueue
the low value and handle the high.
It is also trivial to “delay” the handling to allow more time for high events
to arrive if dealing with synchronized events and you need to account for
jitter.
> On Apr 29, 2021, at 8:10 AM, Øyvind Teig <oyvind.t...@teigfam.net> wrote:
>
> 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:
>>> 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)
>>> However, if highPri has become ready between the first and the second, then
>>> it would be taken (provided lowPri is not also ready)
>>> 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.
>
> --
> 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.
--
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/70379213-0E00-4A9C-A183-A59CCFA10467%40ix.netcom.com.
