Skip to content
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

Add API to force Scheduler to yield for macrotask #25044

Merged
merged 1 commit into from
Aug 5, 2022

Commits on Aug 4, 2022

  1. Add API to force Scheduler to yield for macrotask

    We need a way to yield control of the main thread and schedule a
    continuation in a separate macrotask. (This is related to some Suspense
    optimizations we have planned.)
    
    Our solution needs account for how Scheduler is implemented. Scheduler
    tasks are not 1:1 with real browser macrotasks — many Scheduler "tasks"
    can be executed within a single browser task. If a Scheduler task yields
    control and posts a continuation, but there's still time left in the
    frame, Scheduler will execute the continuation immediately
    (synchronously) without yielding control back to the main thread. That's
    not what we want — we want to schedule a new macrotask regardless of
    where we are in the browser's render cycle.
    
    There are several ways we could approach this. What I ended up doing was
    adding a new Scheduler method `unstable_requestYield`. (It's similar to
    the existing `unstable_requestPaint` that we use to yield at the end of
    the frame.)
    
    It works by setting the internal start time of the current work loop to
    a large negative number, so that when the `shouldYield` call computes
    how much time has elapsed, it's guaranteed to exceed the deadline. The
    advantage of doing it this way is that there are no additional checks in
    the normal hot path of the work loop.
    
    The existing layering between Scheduler and React DOM is not ideal. None
    of the APIs are public, so despite the fact that Scheduler is a separate
    package, I consider that a private implementation detail, and think of
    them as part of the same unit.
    
    So for now, though, I think it makes sense to implement this macrotask
    logic directly inside of Scheduler instead of layering it on top.
    
    The rough eventual plan for Scheduler is turn it into a `postTask`
    prollyfill. Because `postTask` does not yet have an equivalent for
    `shouldYield`, we would split that out into its own layer, perhaps
    directly inside the reconciler. In that world, the macrotask logic I've
    added in this commit would likely live in that same layer. When the
    native `postTask` is available, we may not even need any additional
    logic because it uses actual browser tasks.
    acdlite committed Aug 4, 2022
    Configuration menu
    Copy the full SHA
    5a73703 View commit details
    Browse the repository at this point in the history