On Jan 25, 2017, at 8:00 AM, 'Axel Wagner' via golang-nuts
<golang-nuts@googlegroups.com> 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.
