Track "pending" and "suspended" ranges #16663
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A FiberRoot can have pending work at many distinct priorities. (Note: we refer to these levels as "expiration times" to distinguish the concept from Scheduler's notion of priority levels, which represent broad categories of work. React expiration times are more granualar. They're more like a concurrent thread ID, which also happens to correspond to a moment on a timeline. It's an overloaded concept and I'm handwaving over some of the details.) Given a root, there's no convenient way to read all the pending levels in the entire tree, i.e. there's no single queue-like structure that tracks all the levels, because that granularity of information is not needed by our algorithms. Instead we track the subset of information that we actually need — most importantly, the highest priority level that exists in the entire tree. Aside from that, the other information we track includes the range of pending levels that are known to be suspended, and therefore should not be worked on. This is a refactor of how that information is tracked, and what each field represents: - A *pending* level is work that is unfinished, or not yet committed. This includes work that is suspended from committing. `firstPendingTime` and `lastPendingTime` represent the range of pending work. (Previously, "pending" was the same as "not suspended.") - A *suspended* level is work that did not complete because data was missing. `firstSuspendedTime` and `lastSuspendedTime` represent the range of suspended work. It is a subset of the pending range. (These fields are new to this commit.) - `nextAfterSuspendedTime` represents the next known level that comes after the suspended range. This commit doesn't change much in terms of observable behavior. The one change is that, when a level is suspended, React will continue working on the next known level instead of jumping straight to the last pending level. Subsequent commits will use this new structure for a more substantial refactor for how tasks are scheduled per root.
|
ReactDOM: size: 0.0%, gzip: 0.0% Details of bundled changes.Comparing: 9ce8711...100945b react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
|
acdlite
force-pushed
the
track-pending-and-suspended
branch
2 times, most recently
from
37c942e
to
5d1fe07
Compare
Jessidhia
reviewed
Sep 5, 2019
NE-SmallTown
reviewed
Sep 5, 2019
| return ( | ||
| firstSuspendedTime !== NoWork && | ||
| (firstSuspendedTime >= expirationTime && | ||
| lastSuspendedTime <= expirationTime) |
There was a problem hiding this comment.
FYI, totally I think it's time to rename the name 'expirationTime' because it's been talked/discussed a few months, but for now, since it's a 'time' could we compare them through the 'time order'? I.e. from small to large (lastSuspendedTime <= expirationTime && expirationTime <= firstSuspendedTime)
acdlite
force-pushed
the
track-pending-and-suspended
branch
from
5d1fe07
to
100945b
Compare
This was referenced Sep 6, 2019
sebmarkbage
approved these changes
Sep 10, 2019
sebmarkbage
reviewed
Sep 10, 2019
| if (lastPendingTime < expirationTime) { | ||
| // There's lower priority work. It might be unsuspended. Try rendering | ||
| // at that level immediately, while preserving the position in the queue. | ||
| return renderRoot.bind(null, root, lastPendingTime); |
There was a problem hiding this comment.
We're discussing this. Seems like this refactoring changed things.
There was a problem hiding this comment.
This can be replaced by a prepareFreshStack in an update that happens during a yield.
If the current tree has already determined that it has remaining work at lower pri, we can use that info to eagerly throw to terminate the render and try at lower pri.
sebmarkbage
reviewed
Sep 10, 2019
| // as well start doing that eagerly. | ||
| // just going to try to recover at the pending time anyway so we might as | ||
| // well start doing that eagerly. | ||
| // | ||
| // Ideally we should be able to do this even for retries but we don't yet | ||
| // know if we're going to process an update which wants to commit earlier, | ||
| // and this path happens very early so it would happen too often. Instead, | ||
| // for that case, we'll wait until we complete. | ||
| if (workInProgressRootHasPendingPing) { | ||
| // We have a ping at this expiration. Let's restart to see if we get unblocked. | ||
| prepareFreshStack(root, expirationTime); |
There was a problem hiding this comment.
This can be removed (maybe) because there exists one in the ping function already.
|
Closed by ab4951f |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A FiberRoot can have pending work at many distinct priorities. (Note: we refer to these levels as "expiration times" to distinguish the concept from Scheduler's notion of priority levels, which represent broad categories of work. React expiration times are more granular. They're more like a concurrent thread ID, which also happens to correspond to a moment on a timeline. It's an overloaded concept and I'm handwaving over some of the details.)
Given a root, there's no convenient way to read all the pending levels in the entire tree, i.e. there's no single queue-like structure that tracks all the levels, because that granularity of information is not needed by our algorithms. Instead we track the subset of information that we actually need — most importantly, the highest priority level that exists in the entire tree.
Aside from that, the other information we track includes the range of pending levels that are known to be suspended, and therefore should not be worked on.
This is a refactor of how that information is tracked, and what each field represents:
firstPendingTimeandlastPendingTimerepresent the range of pending work. (Previously, "pending" was the same as "not suspended.")firstSuspendedTimeandlastSuspendedTimerepresent the range of suspended work. It is a subset of the pending range. (These fields are new to this commit.)nextAfterSuspendedTimerepresents the next known level that comes after the suspended range.This commit doesn't change much in terms of observable behavior. The one change is that, when a level is suspended, React will continue working on the next known level instead of jumping straight to the last pending level. Subsequent commits will use this new structure for a more substantial refactor for how tasks are scheduled per root.