Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

This is what my solution does, except that it uses items associated with
priorities instead of 2 channels. if 2 channels are really needed for some
reason, it is easy to adapt the solution to this.


On Fri, May 24, 2019 at 12:12 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> If I had to process messages from both high and low priority channels I
> would serialise then with a min heap and create a consumer process for the
> min heap. The min heap seems to be the canonical way of solving the
> priority queues anyway, so I think it makes sense here.
>
> Basically: goroutine 1 reads both channels and insert them into the
> min-heap. goroutine 2 reads from min heap and do the processing.
>
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em qui, 14 de fev de 2019 às 15:34,  escreveu:
>
>> select {
>> case highVal := <- high:
>> case lowVal := <- low:
>> if len(high) > 0 {
>> for len(high) > 0 {
>> highVal := <- high
>> }
>> }
>> // process lowVal
>> }
>>
>>
>>
>> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>>
>>> Hello,
>>>
>>> i wonder how to implement channel priorities nicely. Say there are two
>>> channels, one with a higher priority than the other, and a goroutine
>>> waiting for incoming data on these channels. I have read that select picks
>>> a random case when multiple channels are ready. I thought of nesting
>>> selects: putting the lower priority select in the default case of the
>>> higher priority select, and have the default case of the inner (low
>>> priority) select do nothing. This leads to a kind of busy wait loop. I
>>> could call a short sleep, but that still isn't very clean. Is there a
>>> better way?
>>>
>>> Why aren't the select cases evaluated in order?
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAEd86TzfnfJMWT8%3D%3Dz5yRMrk0gDZgOLpPLRUO6bdhqs_%2BLB_HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

Daniela, that seems an excellent solution.

On Fri, May 24, 2019 at 12:12 PM Daniela Petruzalek <
daniela.petruza...@gmail.com> wrote:

> If I had to process messages from both high and low priority channels I
> would serialise then with a min heap and create a consumer process for the
> min heap. The min heap seems to be the canonical way of solving the
> priority queues anyway, so I think it makes sense here.
>
> Basically: goroutine 1 reads both channels and insert them into the
> min-heap. goroutine 2 reads from min heap and do the processing.
>
>
> Daniela Petruzalek
> Software Engineer
> github.com/danicat
> twitter.com/danicat83
>
>
> Em qui, 14 de fev de 2019 às 15:34,  escreveu:
>
>> select {
>> case highVal := <- high:
>> case lowVal := <- low:
>> if len(high) > 0 {
>> for len(high) > 0 {
>> highVal := <- high
>> }
>> }
>> // process lowVal
>> }
>>
>>
>>
>> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>>
>>> Hello,
>>>
>>> i wonder how to implement channel priorities nicely. Say there are two
>>> channels, one with a higher priority than the other, and a goroutine
>>> waiting for incoming data on these channels. I have read that select picks
>>> a random case when multiple channels are ready. I thought of nesting
>>> selects: putting the lower priority select in the default case of the
>>> higher priority select, and have the default case of the inner (low
>>> priority) select do nothing. This leads to a kind of busy wait loop. I
>>> could call a short sleep, but that still isn't very clean. Is there a
>>> better way?
>>>
>>> Why aren't the select cases evaluated in order?
>>>
>> --
>> 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.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

*Michael T. jonesmichael.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/CALoEmQwZ0mL-UptRZya17ak%2B4nPYz47tBNsOWNcZDtCWPAsTeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Daniela Petruzalek]

If I had to process messages from both high and low priority channels I
would serialise then with a min heap and create a consumer process for the
min heap. The min heap seems to be the canonical way of solving the
priority queues anyway, so I think it makes sense here.

Basically: goroutine 1 reads both channels and insert them into the
min-heap. goroutine 2 reads from min heap and do the processing.


Daniela Petruzalek
Software Engineer
github.com/danicat
twitter.com/danicat83


Em qui, 14 de fev de 2019 às 15:34,  escreveu:

> select {
> case highVal := <- high:
> case lowVal := <- low:
> if len(high) > 0 {
> for len(high) > 0 {
> highVal := <- high
> }
> }
> // process lowVal
> }
>
>
>
> On Tuesday, July 24, 2012 at 5:16:16 AM UTC+8, Erwin Driessens wrote:
>>
>> Hello,
>>
>> i wonder how to implement channel priorities nicely. Say there are two
>> channels, one with a higher priority than the other, and a goroutine
>> waiting for incoming data on these channels. I have read that select picks
>> a random case when multiple channels are ready. I thought of nesting
>> selects: putting the lower priority select in the default case of the
>> higher priority select, and have the default case of the inner (low
>> priority) select do nothing. This leads to a kind of busy wait loop. I
>> could call a short sleep, but that still isn't very clean. Is there a
>> better way?
>>
>> Why aren't the select cases evaluated in order?
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CA%2B%3Diygt2bxH1E8fkD5JpPV1vKrz2ns%2BD5KpbhZ_SSm2vK%3Dds3w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Michael Jones]

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  wrote:

>
>
> On Fri, May 24, 2019 at 8:40 AM roger peppe  wrote:
>
>> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:
>>
>>> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>>>
 On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  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 t

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:

> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  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).


> There are other issues too: the goroutine effectively acts as an infinite
> buffer, so any back pressure
> from the output channel is lost; if you have a slow receiver, you could
> use a large amount of memory.
> Also, if the input channel is closed, your code will discard any values in
> the buffer: https://play.golang.org/p/5e_E17klnef
> You perhaps want something a bit more like this:
> https://play.golang.org/p/hPHSRvpsqxa
>

This was more a proof of concept than anything else. It would be trivial to
limit the number of inflight items at the cost off blocking on the input
channel. It is also trivial to empty the buffer before closing the output
channel (thanks for the suggestion).


> FWIW the classical way to address the original problem in Go AIUI is to
> select on the
> high priority channels first (with a default clause), and then block on
> all the channels if there's
> nothing immediately ready. This idiom is a bit tedious to generalise to
> multiple channels (first select on c1, then c1, c2, then c1, c2, c3,
> etc until finally select on c1, ... cN), but isn't two bad with two.
>
>  https://play.golang.org/p/pkgZsgENdDb
>

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. In
fact if somehow if you end up with a lot of queued items at priority 100
but you really need something else to be processed immediately, you can
send it at priority 101 and that will work as expected.


>   cheers,
> rog.
>
>
>>
>> On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:
>>
>>> Oops, forgot to include the playground link at the end there:
>>> https://play.golang.org/p/mYSRsGb4mRA
>>>
>>> On Thu, 23 May 2019 at 09:38, roger peppe  wrote:
>>>
 On Thu, 23 May 2019 at 01:34, Anthony Metzidis <
 anthony.metzi...@gmail.com> wrote:

> Fun thought exercise -- here's another approach.
>
>
> https://play.golang.org/p/Xu7iWhY4PUQ
>

 ISTM that that approach doesn't work because you're buffering 10 values
 before you send any.
 So if you have a situation when you've got very little traffic on all
 the channels, a message might
 get delayed indefinitely.

 For example, here's your example with only one message being sent - it
 hasn't arrived
 at the receiver after 5 seconds have elapsed.

   cheers,
 rog.

 --
>>> 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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

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

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

On Fri, May 24, 2019 at 8:40 AM roger peppe  wrote:

> On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:
>
>> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>>
>>> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

On Fri, 24 May 2019 at 16:25, Bruno Albuquerque  wrote:

> On Fri, May 24, 2019 at 1:50 AM roger peppe  wrote:
>
>> On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  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.

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 :)

  cheers,
rog.

-- 
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/CAJhgacgcLCXykA%3D5y4izqVGeC%3D75Yw2qMZX6rcno19QkG5GcuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

On Thu, 23 May 2019 at 19:28, Bruno Albuquerque  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

There are other issues too: the goroutine effectively acts as an infinite
buffer, so any back pressure
from the output channel is lost; if you have a slow receiver, you could use
a large amount of memory.
Also, if the input channel is closed, your code will discard any values in
the buffer: https://play.golang.org/p/5e_E17klnef
You perhaps want something a bit more like this:
https://play.golang.org/p/hPHSRvpsqxa

FWIW the classical way to address the original problem in Go AIUI is to
select on the
high priority channels first (with a default clause), and then block on all
the channels if there's
nothing immediately ready. This idiom is a bit tedious to generalise to
multiple channels (first select on c1, then c1, c2, then c1, c2, c3,
etc until finally select on c1, ... cN), but isn't two bad with two.

 https://play.golang.org/p/pkgZsgENdDb

  cheers,
rog.


>
> On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:
>
>> Oops, forgot to include the playground link at the end there:
>> https://play.golang.org/p/mYSRsGb4mRA
>>
>> On Thu, 23 May 2019 at 09:38, roger peppe  wrote:
>>
>>> On Thu, 23 May 2019 at 01:34, Anthony Metzidis <
>>> anthony.metzi...@gmail.com> wrote:
>>>
 Fun thought exercise -- here's another approach.


 https://play.golang.org/p/Xu7iWhY4PUQ

>>>
>>> ISTM that that approach doesn't work because you're buffering 10 values
>>> before you send any.
>>> So if you have a situation when you've got very little traffic on all
>>> the channels, a message might
>>> get delayed indefinitely.
>>>
>>> For example, here's your example with only one message being sent - it
>>> hasn't arrived
>>> at the receiver after 5 seconds have elapsed.
>>>
>>>   cheers,
>>> rog.
>>>
>>> --
>> 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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/CAJhgacgN_OhK505k9gcufiK_GwwJBWx%3D9qv0wdU5oPg4ViQ6-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Anthony Metzidis]

Good point i'll update with a timeout to flush in case traffic is slow

On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:

> On Thu, 23 May 2019 at 01:34, Anthony Metzidis 
> wrote:
>
>> Fun thought exercise -- here's another approach.
>>
>>
>> https://play.golang.org/p/Xu7iWhY4PUQ
>>
>
> ISTM that that approach doesn't work because you're buffering 10 values
> before you send any.
> So if you have a situation when you've got very little traffic on all the
> channels, a message might
> get delayed indefinitely.
>
> For example, here's your example with only one message being sent - it
> hasn't arrived
> at the receiver after 5 seconds have elapsed.
>
>   cheers,
> rog.
>
>

-- 
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/CADgM4W%2B_cA5kH3zHNxNgELSgg_gH1MGt6R0tjST%2BHeBjGoikeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Bruno Albuquerque]

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.


On Thu, May 23, 2019 at 1:38 AM roger peppe  wrote:

> Oops, forgot to include the playground link at the end there:
> https://play.golang.org/p/mYSRsGb4mRA
>
> On Thu, 23 May 2019 at 09:38, roger peppe  wrote:
>
>> On Thu, 23 May 2019 at 01:34, Anthony Metzidis <
>> anthony.metzi...@gmail.com> wrote:
>>
>>> Fun thought exercise -- here's another approach.
>>>
>>>
>>> https://play.golang.org/p/Xu7iWhY4PUQ
>>>
>>
>> ISTM that that approach doesn't work because you're buffering 10 values
>> before you send any.
>> So if you have a situation when you've got very little traffic on all the
>> channels, a message might
>> get delayed indefinitely.
>>
>> For example, here's your example with only one message being sent - it
>> hasn't arrived
>> at the receiver after 5 seconds have elapsed.
>>
>>   cheers,
>> rog.
>>
>> --
> 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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAEd86TxVW6_vhjTq47pe8z8Rp18CymtD5U1iKBJg%3DB4ufo-HXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

Oops, forgot to include the playground link at the end there:
https://play.golang.org/p/mYSRsGb4mRA

On Thu, 23 May 2019 at 09:38, roger peppe  wrote:

> On Thu, 23 May 2019 at 01:34, Anthony Metzidis 
> wrote:
>
>> Fun thought exercise -- here's another approach.
>>
>>
>> https://play.golang.org/p/Xu7iWhY4PUQ
>>
>
> ISTM that that approach doesn't work because you're buffering 10 values
> before you send any.
> So if you have a situation when you've got very little traffic on all the
> channels, a message might
> get delayed indefinitely.
>
> For example, here's your example with only one message being sent - it
> hasn't arrived
> at the receiver after 5 seconds have elapsed.
>
>   cheers,
> rog.
>
>

-- 
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/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[roger peppe]

On Thu, 23 May 2019 at 01:34, Anthony Metzidis 
wrote:

> Fun thought exercise -- here's another approach.
>
>
> https://play.golang.org/p/Xu7iWhY4PUQ
>

ISTM that that approach doesn't work because you're buffering 10 values
before you send any.
So if you have a situation when you've got very little traffic on all the
channels, a message might
get delayed indefinitely.

For example, here's your example with only one message being sent - it
hasn't arrived
at the receiver after 5 seconds have elapsed.

  cheers,
rog.

-- 
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/CAJhgaciF8KDP%2BT3x5UVdqB5JoD7N6pLurkYUViertauELRaP5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: how to implement channel priorities?

[Anthony Metzidis]

Fun thought exercise -- here's another approach.


https://play.golang.org/p/Xu7iWhY4PUQ
package main

import (
"fmt"
"math/rand"
"sort"
"time"
"strconv"
)

type PriorityStruct struct {
Pint
name string
}

const BUFSIZE = 10

type PriorityChan chan PriorityStruct
type PriorityBuf []PriorityStruct

func (s PriorityBuf) Len() int {
return len(s)
}
func (s PriorityBuf) Swap(i, j int) {
s[i], s[j] = s[j], s[i]
}
func (s PriorityBuf) Less(i, j int) bool {
return s[i].P < s[j].P
}

func Sender(pchan PriorityChan) {
for {
randNum := rand.Intn(3)
pchan <- PriorityStruct{
P:randNum,
name: "Bob-" + strconv.Itoa(randNum),
}
time.Sleep(10 * time.Millisecond)
}
}

func Prioritize(inChan PriorityChan, outChan PriorityChan) {
for {
buf := make(PriorityBuf, BUFSIZE)
for i, _ := range buf {
buf[i] = <-inChan
}
sort.Sort(buf)
for i, _ := range buf {
outChan <- buf[i]
}
}
}

func Receiver(rchan PriorityChan) {
for {
fmt.Printf("%v\n", <-rchan)
}
}

func main() {
inChan := make(PriorityChan)
outChan := make(PriorityChan)
go Sender(inChan)
go Receiver(outChan)
go Prioritize(inChan, outChan)
<- time.After(5 * time.Second)
}

-- 
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/CADgM4WLa32XWs7-jSM6J3p_QMMN9tnk%3DSjNxOSg34XZ7PHJDgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.