Glad someone mentioned reflect.Select. Implemented simple round robin
solution with a timeout case (if no data is available at all) using just
that .
To add to some priority would be just be a matter of setting the
channel/cases to nil after several writes, rather than just after one like
I do. Lower priority cases would get set to nil sooner.
The other reason I needed reflect.Select was because the number of channels
being polled changes at runtime.
I agree with Wim that you can probably implement quite a few things using
that - with priority just being one of them.
It does seem like use of reflect.Select would be really wasteful to use
inside a loop but in my case at least I did not notice any problems (sorry
don't have more scientific numbers than that).
Cheers
Jakub
On Thursday, January 26, 2017 at 12:20:50 AM UTC, Wim Lewis wrote:
>
>
> On Jan 25, 2017, at 8:00 AM, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com <javascript:>> wrote:
> > It's also a feature rabbit-hole. I'd predict, that next up, someone who
> experiences starvation wants to add weighted scheduling ("give this case an
> 80% chance of succeeding and this other case 20%, so that eventually either
> will proceed") or more complicated scheduling strategies.
> >
> > I think such edge-cases for scheduling requirements should rather be
> implemented separately in a library. Yes, it's complicated code, but that's
> all the more reason why it shouldn't be in everyone's go runtime.
>
> Since it is an edge case, but one which has legitimate (if idiosyncratic)
> uses, maybe the best approach would be to implement only enough in the go
> runtime to allow people to implement what they want. It seems to me that
> the minimal functionality needed would be a "non-receiving select". In
> other words, an addition to the reflect package which would allow people to
> efficiently wait for any of N channels to become receivable, without
> actually receiving anything.
>
> Straw-man suggestion: a function reflect.TestSelect(cases []SelectCase) ->
> []int
>
> which blocks until at least one case can proceed, and then returns a list
> of all cases which could proceed without blocking. Given that primitive,
> people can implement whatever behavior they want, and the primitive itself
> is fairly simple and well-defined.
>
> Another option that occurs to me is to add a bool to the SelectCase struct
> which tells select, "block on this, but don't actually perform the action",
> but I think that would be less clean.
>
>
>
>
--
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.
