I wasn't entirely sure whether this should return a value or a pointer to
satisfy the interface. Both works, so I benchmarked it elsewhere (REST
mapper). Mem allocs are the same (one alloc/call), but returning a value is 10%
slower when calling one method.
What I then benchmarked is whether pointer vs value receiver in the wrapper
makes a difference. Converting from value receiver (what I had before) to
pointer receiver reduced call overhead by 6%. That's because with a value
receiver, Go has to auto-generate a variant with pointer receiver and calls the
value receiver through that.
That can be seen in a debugger (call stack) and when setting breakpoints:
(dlv) b restMapperWrapper.KindForWithContext
Command failed: Location "restMapperWrapper.KindForWithContext" ambiguous: k8s.io/apimachinery/pkg/api/meta.restMapperWrapper.KindForWithContext, k8s.io/apimachinery/pkg/api/meta.(*restMapperWrapper).KindForWithContext…
Conventional wisdom is to define types with value receiver because those can be
called also on unmutable instances, making them more flexible.
But for types which will only ever be used via a pointer, I think pointer
receiver is better for the reasons above (small performance difference, easier
to debug).
Kubernetes-commit: b21dcbcaa1ccf4995bf486afc37dc0321c5bdf0b
Signed-off-by: Min Jin <minkimzz@amazon.com>
Update staging/src/k8s.io/client-go/tools/cache/the_real_fifo.go
optimizing fifo loop
Co-authored-by: Marek Siarkowicz <marek.siarkowicz@protonmail.com>
Signed-off-by: Min Jin <minkimzz@amazon.com>
refactoring PopBatch to accept []Delta
Signed-off-by: Min Jin <minkimzz@amazon.com>
Kubernetes-commit: 611b4c1408f529de4d4e94e6dd33be2ed1df9276
returns a ListerWatcher that knows whether the provided client explicitly
does NOT support the WatchList semantics. This allows Reflectors
to adapt their behavior based on client capabilities.
Kubernetes-commit: 3b93755c0c07ce898f1c2a3924adef6c3143f247
updating to include initialization in func
Update store to use sets.Set
updating tests to use sets.New instead of sets.NewString
update store_test
update index_test
update controller_test file
update delta_fifo file
update expiration_cache_fakes file
update index_test file
update thread_safe_store file
update events_cache file
update thread_safe_store_test
update expiration_cache_test
small refactor of for loop
unexport the Index type -> index
Kubernetes-commit: c08b9ab3b5c78023e46ce03fde894b24533c68ef
* cache: do not allocate chan for nothing
The explicit purpose of this channel is to never be closed and nothing
to be sent down on it. Hence, there's no need to allocate a channel - a
nil channel has exactly the desired behaviour.
Additionally, this is more relevant now that testing/synctest gets
unhappy when goroutines are blocked on reading on channels which are
created outside of the synctest bubble. Since this is a package var, that's
hard to avoid when using this package. Synctest is fine with nil
channels though.
Reported-by: Jussi Maki <jussi@isovalent.com>
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
* handlers: do not allocate chan for nothing
Nil chan has the desired semantics already, and this breaks
testing/synctest because the channel is allocated outside of the bubble.
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
---------
Signed-off-by: David Bimmler <david.bimmler@isovalent.com>
Kubernetes-commit: 52b7d035f9655d0c6ebeaaafd60add99700bb468
This raises awareness so that developers hopefully get it right without having to
learn about it from compile errors. It also explains that creating a PR to
fix the naming is not desired.
Kubernetes-commit: f40892f4813f29fc305d59073d2464a1fd7d6fe5
- Add a new VeryShortWatchError struct for error matching, returned
by `handleAnyWatch`, up through `Reflector.ListAndWatch`.
- Update test expectations to match exact errors.
Kubernetes-commit: 6eff9db0f10db72f2c64390e106a80621d136439
Change:
- refactor Reflector.ListAndWatch and Reflector.watch to always call
watcher.Stop.
- refactor Reflector.handleAnyWatch to always call watcher.Stop,
EXCEPT when exitOnWatchListBookmarkReceived &&
watchListBookmarkReceived.
- Update unit tests with these new expectations.
Effect:
- ensures watcher.Stop is always called at least once
- avoids deadlocks in watcher implementations when watcher.Watch is
called, but watcher.Stop is never called.
Note: It's impossible to guarantee that Stop will only be called once.
So watch.Interface implementations must tollerate Stop being called
multiple times.
Kubernetes-commit: 3e609ecf6e945bf4562bddfc563fde9a4c3d0d90
The Lister and Watcher interfaces only supported methods without context, but
were typically implemented with client-go API calls which need a context. New
interfaces get added using the same approach as in
https://github.com/kubernetes/kubernetes/pull/129109.
Kubernetes-commit: 6688adae142e37114d9dfa8d94cd1d8a91fbcc13
