-
Notifications
You must be signed in to change notification settings - Fork 314
Cancel preparation tasks for editor functionality if the preparation task hasn't been started yet and the document is no longer active #1323
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
Conversation
10df160
to
17e9205
Compare
@swift-ci Please test |
@swift-ci Please test Linux |
17e9205
to
99d7a88
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
@swift-ci Please test Linux |
@swift-ci Please test Windows |
99d7a88
to
bb1529c
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
…task hasn't been started yet and the document is no longer active When the user opens documents from three targets A, B, and C in quick succession, then we don’t want to schedule preparation of wait until A *and* B are finished preparing before preparing C. Instead, we want to - Finish for preparation of A to finish if it has already started by the time the file in C is opened. This is done so we always make progress during preparation and don’t get into a scenario where preparation is always cancelled if a user switches between two targets more quickly than it takes to prepare those targets. - Not prepare B because it is no longer relevant and we haven’t started any progress here. Essentially, we pretend that the hop to B never happened.
bb1529c
to
41b810b
Compare
@swift-ci Please test |
@swift-ci Please test Windows |
1 similar comment
@swift-ci Please test Windows |
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.
LGTM
if inProgressPrepareForEditorTask?.id == id { | ||
inProgressPrepareForEditorTask = nil | ||
} |
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.
When is just checking document
not enough?
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.
- You open document A and it gets prepared for editor functionality
- You open document B, which should cancel the preparation for A, cancellation doesn’t get checked at this exact moment, so A’s preparation continues running for a bit longer
- You open document A again
- The preparation of A from (1) finishes now and gets to this state. But the preparation of A from (3) is still running, so we can’t set
inProgressPrepareForEditorTask
tonil
Checking Task.isCancelled
before setting inProgressPrepareForEditorTask
to nil
also isn’t an option because that would mean that inProgressPrepareForEditorTask
got cancelled without a new preparation for editor task beings scheduled. I don’t think that can happen right now but it’s not unreasonable to assume that inProgressPrepareForEditorTask
could get cancelled for whichever reason in the future.
When the user opens documents from three targets A, B, and C in quick succession, then we don’t want to schedule preparation of wait until A and B are finished preparing before preparing C.
Instead, we want to