Re: [w3ctag/design-reviews] Early design review: scheduler.yield() (Issue #827)

Hi,

@plinss and I took a look at this during our Tokyo F2F this week. Overall, we like the idea of a simple API a developer can use to yield back to the event loop mid-computation. Here are a few specific things we noticed while reviewing the explainer, and one general worry:

* @plinss noticed the `"signal"` option name might confuse developers because it seems inconsistent with the `"signal"` option of the Fetch API. Maybe renaming it to "task signal" or something like that would help?
* Browser engines have very different implementations of the event loop and associated concepts; are the parameters in the options bag hints that the engine can ignore if necessary, or are they required to be respected? Also, if the options bag can be ignored, would it be possible to polyfill this using a noop async function?

A general concern: In isolation, this seems like a very sensible API. But it's part of a much larger project and it's unclear to us if there has been much external review (especially from other implementors) of the Scheduler API project as a whole. Relatedly, this builds on some other API (e.g. `TaskController`) that are only implemented in Blink. It often worries us when new technology is built on top of other technology that does not yet have multi-implementor buy-in, or better yet, multiple shipping implementations.

Anyway, this strikes us as a simple and ergonomic way for developers to do something quite common. Please ask us to review the "bigger picture" of the Scheduler API, and we'd love to take a look at `scheduler.yield()` again should it (or its dependencies) significantly change. Thanks!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/827#issuecomment-1513962941
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/827/1513962941@github.com>