Skip to content

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