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
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 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.
