I see an easy* way to implement channel priorities in Go2 if that is
desired.
two steps:
step 2: At lines 124 and 153-157 of src/runtime/select.go, an *order of
channel testing* index table is created, then permuted.
It is later visited in order. All that needs doing is to make the index
table larger by repeating channel indices based on relative priority.
example:
channels a,b,c of equal priority:
pollorder = permute[a,b,c]
channels a,b,c of priority a=5,b=2,c=1:
pollorder = permute[a,a,a,a,a b,b, c]
step 1:Somehow convey priorities from developer's Go source to select.go.
Open issue, many choices, matter of taste. One idea is explicit parameter
in select, another is to allow cases to repeat and count them, or
equivalently, allow the "comma list of channels" with repeats.
select {
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg1 := <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
}
select {
case msg1 := <-c1, <-c1:
fmt.Println("received", msg1)
case msg2 := <-c2:
fmt.Println("received", msg2)
}
Each of these means c1 is 2x and c2 is 1x out of a total of 3, for c1 is 2x
the priority of c2 and is selected 2/3 of the time on average when both
channels have data. Since a deranged developer might copy/paste the "<-c1"
a hundred times, and "<-c2" fifty, the compiler should preferably optimize:
g = gcd(list of priorities)
[list of priorities]/=g // defend against needless scales in priorities,
ivy-like syntax
Michael
*easy to conjecture.
On Fri, May 24, 2019 at 9:18 AM Bruno Albuquerque <b...@gmail.com> wrote:
>
>
> On Fri, May 24, 2019 at 8:40 AM roger peppe <rogpe...@gmail.com> wrote:
>
>> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque <b...@gmail.com> wrote:
>>
>>> On Fri, May 24, 2019 at 1:50 AM roger peppe <rogpe...@gmail.com> wrote:
>>>
>>>> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque <b...@gmail.com> wrote:
>>>>
>>>>> This was my attempt at a channel with priorities:
>>>>>
>>>>>
>>>>> https://git.bug-br.org.br/bga/channels/src/master/priority/channel_adapter.go
>>>>>
>>>>> Based on the assumption that priorities only make sense if items are
>>>>> queued. If they are pulled out from a channel as fast as they are added to
>>>>> it, then there is no need for priorization.
>>>>>
>>>>
>>>> I'm not entirely sure that's the right assumption. The original request
>>>> is about having priority
>>>> between different channels. If there's a value available on both
>>>> channels, you only ever want to
>>>> process the high priority one. With your code, however, if you've got
>>>> two goroutines sending and the
>>>> output channel is always ready to receive, the priority is decided by
>>>> goroutine scheduling, and
>>>> the low priority channel can win inappropriately:
>>>> https://play.golang.org/p/YBD_w5vVqjt
>>>>
>>>
>>> My code actually uses a single channel and deals with relative
>>> priorities between items added to the channel. The original problem can be
>>> morphed to this by using only 2 priorities. I honestly do not think that
>>> worrying about 2 values being sent by 2 different go routines at nearly the
>>> same time is something one needs to worry about. This is similar to having
>>> 2 entries sent to individual channels at nearly the same time but with
>>> enough skew that the low priority one arrives before the higher priority
>>> one does (so it will be processed first unless there is a forced delay
>>> added (as seem on the other approach).
>>>
>>
>> One example scenario when you might want to have priority receiving on
>> two different channels (which was after all the question that started this
>> thread), is when you're receiving messages from a high-volume buffered
>> channel, and a low volume synchronous channel (for example, a channel
>> returned from context.Done). If you get a value from the Done channel, you
>> want to quit as soon as possible. If you just use a regular select, you can
>> end up processing an unbounded number of messages before you decide to quit.
>>
>
> And you could easily do that with a select on the channel I return and the
> done channel. Also this is a very specific scenario you propose. For
> specific scenarios one can almost always find specific non-generic
> solutions that are better than a generic one. My solution tries to address
> the general case of dealing with prioritizing items in a channel.
>
>
>> There is one big advantage with my solution: You can actually model any
>>> reasonable number of priorities you might need without any code changes
>>> whatsoever. It can handle 2 priorities as well as it can handle 100.
>>>
>>
>> If I may say so, there's one significant disadvantage of your solution:
>> it doesn't solve the original problem :)
>>
>
> You you take the original question literally, you are obvious right. But
> it the original question can be relaxed to "I want to handle items with
> different priorities" which, as I mentioned, the original problem can be
> reduced to, then no, you are not.
>
> Anyway, I am fine with agreeing to disagree.
>
>
> --
> 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/CAEd86Tym8dvnBHQj6Oudyc_K31-HgG-s4cQjB%3DbNzSpX11HKtw%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAEd86Tym8dvnBHQj6Oudyc_K31-HgG-s4cQjB%3DbNzSpX11HKtw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.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/CALoEmQzKLxSFouPZTRr-y_XLmfr9OcRLicSaZ27NzrUG2g9Apw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
