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. For more options, visit https://groups.google.com/d/optout.
