You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Mozillians who can provide input (optional): @smaug---- (reviewer on the PR)
Other information
Memory management
Composite signals (those created by this API) need to be kept alive as long as they can be aborted and have 'abort' event listeners or pending abort algorithms (the spec PR has a note about this). As part of implementing this In Chromium, we needed to make sure abort algorithms were being removed when they were longer needed, e.g. when all fetch state is GCed and the signal can no longer affect the fetch or response. See also this issue.
As mentioned in the explainer, there's a specialization for TaskSignal.any() so the returned signal also has priority. The draft spec PR is here, which mirrors the DOM PR.
The text was updated successfully, but these errors were encountered:
I think this looks very reasonable, useful small addition to an existing API.
The pr has possibly just very minor issues.
I'd say we could be positive about this.
(TaskSignal.any is then different topic, since it is still a bit unclear whether Scheduler API is useful.)
Request for Mozilla Position on an Emerging Web Specification
Other information
fetch
state is GCed and the signal can no longer affect the fetch or response. See also this issue.TaskSignal.any()
so the returned signal also has priority. The draft spec PR is here, which mirrors the DOM PR.The text was updated successfully, but these errors were encountered: