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