Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make Executors have deterministic shutdown #5547
Make Executors have deterministic shutdown #5547
Changes from 23 commits
2ab887b
0e7b490
2f5b8fd
7581567
832791f
5542371
b510bad
752a828
6aae53e
0919154
e57f647
5d094d0
65f0490
a4f1272
31bd970
ceb3aa9
f608cb0
69e8876
3af0346
bf30968
1fd787a
faf1d51
4ad7557
7d7b467
1dc9e36
0ba4d16
deb6774
f29f5ad
1725ecf
adb51fb
1d87757
bffaee3
c2c282d
b0db78a
4f85358
1182d86
167394a
e9ad380
367c93d
a5766b1
619c039
3edbaec
43eefae
3f52fc6
ed7d38a
8c2c9a6
48e3aea
d0ee6f4
3e404a8
34d7876
b341c17
786f29a
4f6c82e
f534aaa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Optional: I think it's slightly strange that
Executor::Id
refers to the id of an operation, not the id of the executor. On the other hand, I can understand the desire for brevity.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just promoting
ExecutorStd::Id
toExecutor
(and removing the separate implementation fromTimeSlot
). I figured this would be noncontroversial without considering this too deeply.If you'd like to revisit the original name from
ExecutorStd
I'm happy to do so, but need some ideas about what you'd find acceptable. Is this a sequence number? A task id? Should I moveId
andTag
toTask
? One argument against that is that nested types cannot be forward declared, which means that suddenlyTask
would get much wider exposure.FWIW I'm OK with this as-is, but again, I'm happy to work to make this better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have any particular preference re. moving these to
Task
-- this might be a little more natural, but I don't think it justifies the practical concerns you mention. I thought about simply making theseExecutor::TaskId/TaskTag
. If you have any objection to that, I'm absolutely fine with keeping the status quo.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me defer this for now. I'd like to address this naming concern along with the inability of most consumers of Executor/AsyncQueue being unable to forward declare them in a holistic fashion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same nit here:
Executing
, etc. should be lowercase.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Also canceling -> cancelling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Brainstorm: from the name of this function, I would expect different semantics (like the comment seems to anticipate). To throw out some suggestions:
Disown
,Release
,Detach
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is more of an event callback I changed it to
OnCompletion
. I specifically want to avoidRelease
since that's an imperative name for something that implies a definite decrement of the reference count, but that's not happening here at all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously,
Try
in the function name indicated that this function is not guaranteed to succeed (because it is unable to cancel an already started operation). This seems like something worth reminding the caller about, what is the rationale for removing it? (Note: I don't think there's any general requirement that aTryFoo
function must return a boolean)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While there's no requirement that methods with a "try" prefix return a boolean they typically are designed to allow the caller to handle failure. For example,
std::mutex::try_lock
, clearly makes a style of programming possible wherein the caller can take action based on whether the lock was acquired or not. My take is that "try" in a method name isn't an indicator of possible failure or idempotency (because many methods have that property without being prefixed with "try"), but rather that "try" intends for the caller to discriminate. In this case I felt that the caller shouldn't care and so the "try" wasn't helpful.Meanwhile, this was particularly apparent to me because
DelayedOperation::Cancel
is the actual API for cancelation used in the rest of our code. I madeTryCancel
private, accessible only to friends, and renamed it to match its caller.Also FWIW, note that in google3,
CancellableClosure
has aCancel
even though it does allow discrimination.