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). > 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 <rogpe...@gmail.com> 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 <rogpe...@gmail.com> 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 >>> <https://groups.google.com/d/msgid/golang-nuts/CAJhgaciGHN633%2BCWtYE6Gw4i8pdB9XoQ5HbOiHR1X06oJxMdCQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> 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/CAEd86Twc3FGNU%2B1RVHef2B5UNWfV_44DnMLShm-MqdhA1xcdOQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
