Documentation
¶
Overview ¶
Package armnotify carries the arming verdict for a claimed sandbox from the post-start hook runner to the create request waiting on it.
Both live in the same process — cmd/sandbox runs the controller manager and the API server together — so this is a channel handoff, not a distributed problem. The alternative was to record the verdict on the Pod and have the create path watch for it, which spends one API-server write per sandbox, fanned out to every Pod informer in the cluster, to move a fact between two goroutines that already share an address space.
The registry is deliberately not a cache: an entry exists only while someone is waiting for it, and a verdict with no waiter is dropped. Nothing here is state, so nothing here needs cleaning up on restart.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Registry ¶
type Registry struct {
// contains filtered or unexported fields
}
Registry routes arming verdicts to the goroutine waiting for them.
func (*Registry) Notify ¶
Notify delivers a verdict. err nil means the sandbox is armed.
A verdict for a sandbox nobody is waiting on is dropped, which is the normal case for the re-arm that follows a configuration change: that work has no requester.
func (*Registry) Wait ¶
Wait registers interest in a sandbox's arming verdict and returns the channel it will arrive on, plus a cancel function the caller must defer.
Register before the work can start, not after: a verdict that arrives while no waiter is registered is dropped, and the caller would then wait for one that has already been delivered.
A second Wait for the same sandbox replaces the first, and the displaced waiter is failed rather than left hanging: one request claims one sandbox, so this cannot happen for a live claim, but a waiter that can never be notified would block for its whole deadline if it ever did.
Source Files