I sent that to the wrong entry! Is it possible that you could make a code
example?
torsdag 29. april 2021 kl. 15:20:40 UTC+2 skrev ren...@ix.netcom.com:
> 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 <oyvin...@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:
>>>
>>> 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...@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
>
> <https://groups.google.com/d/msgid/golang-nuts/cf43611c-599f-46d9-98ac-60ede00daea9n%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/ac6eecc4-ee82-4a21-9001-b2c704e74e8cn%40googlegroups.com.
