Please, drop it. You don't know what you're talking about. I've been amazed
at how patient everyone has been. I think it's time to be more blunt in
pointing out you don't understand concurrency and independent events.
On Fri, Oct 4, 2019 at 3:15 PM T L <tapir....@gmail.com> wrote:
>
>
> On Friday, October 4, 2019 at 5:40:08 PM UTC-4, ohir wrote:
>>
>> On Fri, 4 Oct 2019 13:52:19 -0700 (PDT)
>> T L <tapi...@gmail.com> wrote:
>>
>> > One priority-order select block is not only cleaner than two
>> random-order
>> > select blocks, but also more efficient.
>>
>> It is neither.
>>
>> 1. It is not cleaner, because you would need to somehow denote
>> priorities.
>> If you think now about "in written order", you should think of the most
>> frequent
>> cases that you do not want to have all five, ten, twenty cases be
>> serviced
>> on order. Not to mention that down the road someone might introduce an
>> unnoticeable bug for pure aesthetic reasons.
>>
>> 2. It is not more efficient, it is less efficient because every select
>> operation
>> would need at least a "priority comparison" op, or - in general case - a
>> sort
>> op, because not only two channels can be ready, it may happen that all of
>> them will. This would have to run for every select then, unless
>> introduced by a "select_with_priorities" keyword.
>>
>>
> select(ordered) {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
>
> is undoubtedly more efficient than
>
> select(randomized) {
> case <-ctx.Done():
> return ctx.Err()
> default:
> }
> select(randomized) {
> case <-ctx.Done():
> return ctx.Err()
> case out <- v:
> }
>
> Not only one less try-receive operation is saved,
> but also is the step 2 described in
> https://go101.org/article/channel.html#select-implementation saved.
>
>
>
>> 3. Others tried to no avail, I will too in other words:
>>
>> The select switch is deliberately randomized because language creators
>> envisioned that otherwise someone would be "smart" and will use
>> ordering to impose a **dependency** where it should not be made.
>>
>> Channel operations serviced by select are treated as sourced
>> from **independent** events. Period.
>>
>> If your out <-v must be dependent of ctx.Done not being ready you
>> must resolve this dependency by other means. Eg. by selecting for it
>> in separate select before.
>>
>
> It is not a must. It just tries to select ctx.Done if possible.
> In fact, if the two evens are independent with each other,
> there is no way to absolutely ensure the must.
>
>
>>
>> Hope this helps,
>>
>
> You can read the first comment in this thread for another use case of
> priority-order
> select block.
>
>
>>
>> --
>> Wojciech S. Czarnecki
>> << ^oo^ >> OHIR-RIPE
>>
> --
> 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/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/0c9aaa9b-ea9d-49f5-a1b4-4f94ee0de424%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank
--
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/CABx2%3DD9NnBkz0jCcXM7x%3D4Ms6rw0L%2BmrWGsknD3_kKM_9mMnzw%40mail.gmail.com.
