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

Expose everywhere #51

Closed
wants to merge 1 commit into from
Closed

Expose everywhere #51

wants to merge 1 commit into from

Conversation

Ms2ger
Copy link

@Ms2ger Ms2ger commented Oct 20, 2021

@shaseley
Copy link
Collaborator

This would expose the interfaces on other globals (i.e. worklets), but wouldn't make them particularly useful since they're used in conjunction with self.scheduler, exposed here via a WindowOrWorkerGlobalScope mixin. If we were to change that, we'd need to also update some of the algorithms since we assume either a window or worker (e.g. step 7 here).

But I'm wondering whether or not worklet global scopes (and maybe by extension shadow realms) should expose a Scheduler. Scheduler runs tasks async and is tightly coupled with the event loop; worklets seem to have different expectations around the event loop and asnyc tasks, specifically that spec text leads me to believe they shouldn't be running async tasks (the part about not needing to run continuously). I'm not all that familiar with worklets, however.

/cc @domenic who might have some more context/thoughts.

@shaseley shaseley self-requested a review October 20, 2021 21:18
@domenic
Copy link
Collaborator

domenic commented Oct 29, 2021

Yeah. Although I applaud the general tendency toward being maximal in what we expose, I think the particular case of scheduling---both this API, and things like setTimeout/setInterval---are probably best not exposed in all realms.

In particular, worklet realms are designed to have a minimal event loop, that could be implemented as only ever running one task + associated microtasks, per instantiation of the WorkletGlobalScope. So anything that allows scheduling work in separate future tasks would break that.

@Ms2ger
Copy link
Author

Ms2ger commented Jan 18, 2022

@domenic oh, looks like I missed the comments here before. I don't have strong feelings about this myself; this PR was based on my understanding that you & Dan had agreed it would be useful to expose. Unless @leobalter disagrees, I'm happy to drop this if you changed you mind, though.

@leobalter
Copy link

leobalter commented Jan 18, 2022

I'm fine with it either way.

cc @caridy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants