On Thu, Apr 29, 2021 at 2:26 PM Øyvind Teig <oyvind.t...@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+unsubscr...@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/CAEkBMfG3QM-TY8Hp3pA6L4%2B%2BX8-zkWqHwgSGuYTBMQnN_EXk8A%40mail.gmail.com.
