Simplified and corrected logic around context cancelation #87059
Conversation
k8s-ci-robot
added
release-note-none
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: MikeSpreitzer The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
(1) Replaced random-looking assortment of counter increments and decrements with something hopefully more principalled-looking. Most importantly, introduced the MutablePromise abstraction to neatly wrap up the complicated business of unioning multiple sources of unblocking. (2) Improved debug logging. (3) Somewhat more interesting test cases, and a bug fix wrt round robin index.
|
@tedyu |
|
|
||
| // Readable is a variable that is initially not set and later becomes |
There was a problem hiding this comment.
variable: it is an interface.
Please rephrase
| IsSet() bool | ||
| } | ||
|
|
||
| // ReadableLocked is a Readable whose implementation is protected by a lock |
There was a problem hiding this comment.
ReadableLocked: wrong type name
There was a problem hiding this comment.
Yes, editing oversight.
| } | ||
|
|
||
| // ReadableLocked is a Readable whose implementation is protected by a lock | ||
| type LockingReadable interface { |
There was a problem hiding this comment.
From the func names below, it seems Locked is better than Locking
There was a problem hiding this comment.
"locked" is a state that a mutex may or may not be in; entered via Mutex::Lock() and exited by Mutex::Unlock(). I am following the convention here that ending a method name in "Locked" signals that the caller must already have locked the mutex. I chose "LockingReadable" rather than "LockedReadable" because the Readable's mutex is not always locked, rather I am trying to signal that locking is part of how the Readable works.
|
Thanks, @tedyu . |
|
@tedyu , would you like to take another look? |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
| break | ||
| } | ||
| } | ||
| return |
There was a problem hiding this comment.
after remove canceled req, totRequestsWaiting also needs to be decremented
k8s-ci-robot
removed
the
lgtm
|
New changes are detected. LGTM label has been removed. |
|
/retest |
Previously, a `decisionCancel` could overwrite a `decisionReject` or `decisionExecute`, causing confusion. Now a request gets exactly one decision and there is no confusion. Also added write-once to the promise package and refactored.
MikeSpreitzer
force-pushed
the
limited-cancel
branch
from
220dd3f
to
db4ba1c
Compare
|
The force-push to db4ba1c is a squash. |
|
@MikeSpreitzer: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
|
See #87362 instead of this one. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR tightens up the logic around cancelation of the context.Context. Previously a request could get more than one decision (in series), with a decisionCancel overwriting a decisionReject or decisionExecute and causing confusion. Now a request gets exactly one decision, and QueueSet allows context cancelation to only cut short the time spent waiting in the queue. This PR also adds a QueueSet test for context cancelation. This PR also fixes a metrics oversight.
There is no official issue for this PR, but the problem was reported in a conversation that ended at MikeSpreitzer@1c31b2b#r36721437 .
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: