keep WorkletGlobalScope as long as its Worklet exists

RESOLVED FIXED in Firefox 68

Status

()

enhancement
P2
normal
RESOLVED FIXED
3 months ago
3 months ago

People

(Reporter: karlt, Assigned: karlt)

Tracking

(Blocks 1 bug)

Trunk
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(4 attachments)

For AudioWorklet at least, we want a one-to-one mapping of Worklet and WorkletGlobalScope.

https://webaudio.github.io/web-audio-api/#audioworkletglobalscope

Exactly one AudioWorkletGlobalScope exists for each AudioContext that contains one or more AudioWorkletNodes.

https://webaudio.github.io/web-audio-api/#AudioWorklet-Sequence

  1. An AudioContext is created.
  2. In the main scope, context.audioWorklet is requested to add a script module.
  3. Since none exists yet, a new AudioWorkletGlobalScope is created in association with the context. This is the global scope in which AudioWorkletProcessor class definitions will be evaluated. (On subsequent calls, this previously created scope will be used.)
  4. The imported script is run in the newly created global scope.

Non-audio worklets can be permitted to have multiple global scopes with different lifetimes, but having a single WorkletGlobalScope is still a simple way to satisfy the requirement that all module scripts are run in each WorkletGlobalScope.
https://www.w3.org/TR/worklets-1/#creating-a-workletglobalscope

https://www.w3.org/TR/worklets-1/#lifetime-of-the-worklet

The lifetime of a WorkletGlobalScope should be defined by subsequent specifications which inherit from WorkletGlobalScope.

Depends on: 1539045
Priority: -- → P2

AudioDestinationNode, AudioContext, and Worklet are part of the same cycle.
Any of these may be unlinked before another.
The unlink process for this cycle is the notification that the worklet will no
longer be used, but the worklet uses the destination stream to send a message
to release graph thread objects and so must do this before the stream is
destroyed.

On process shutdown, the MSG is shut down (and so are other threads) before
the final main thread cycle collection, and so we can't depend on unlink to
notify the worklet before MSG shutdown.

Depends on D25351

This gives WorkletImpl a chance to send a message to release worklet thread
objects.

This is used only for PaintWorklet until PaintWorklet uses its own threads.

Depends on D25352

Attachment #9054402 - Attachment description: Bug 1539039 notify WorkletImpl before WorkletThread shutdown on xpcom shutdown r?baku → bug 1539039 notify WorkletImpl before WorkletThread shutdown on xpcom shutdown r?baku

Comment 5

3 months ago
Pushed by ktomlinson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/973f69d0a810
finish worklet before destination stream is destroyed r=padenot
https://hg.mozilla.org/integration/autoland/rev/f3098fb60d80
shutdown worklet from AudioContext::Shutdown() r=padenot
https://hg.mozilla.org/integration/autoland/rev/62a25408f9ea
notify WorkletImpl before WorkletThread shutdown on xpcom shutdown r=baku
https://hg.mozilla.org/integration/autoland/rev/80bda5c60103
keep WorkletGlobalScope as long as its Worklet is usable r=baku
You need to log in before you can comment on or make changes to this bug.