You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the server code manages a set of typed channels/cancelations/etc. and an untyped aggregation goroutine that allows for handling generic types. This is done because of how select only supports a static number of channels. As a result of this, there is a lot of duplicated code between the typed branches and a different set of logic handling the unknown types.
We might consider using reflect.Select here in order to treat all the channels the same: this would not only reduce the amount of code duplication, but also reduce the number of goroutines used when unknown types are subscribed to.
Currently the server code manages a set of typed channels/cancelations/etc. and an untyped aggregation goroutine that allows for handling generic types. This is done because of how
select
only supports a static number of channels. As a result of this, there is a lot of duplicated code between the typed branches and a different set of logic handling the unknown types.We might consider using
reflect.Select
here in order to treat all the channels the same: this would not only reduce the amount of code duplication, but also reduce the number of goroutines used when unknown types are subscribed to.https://github.com/envoyproxy/go-control-plane/compare/main...snowp:dynamic-select?expand=1 shows a prototype of
reflect.Select
in action: we manage a list of channels to subscribe from based on, and usereflect.Select
to pick between the watch channels, the request channel andctx.Done
.Putting this up for thoughts in case I'm missing any cons with the reflection approach here.
The text was updated successfully, but these errors were encountered: