Event Loop execution in `closed` state about web-audio-api HOT 3 CLOSED

The close() method will not automatically release all AudioContext-created objects.

A close() is also available on the MessagePort and useful for releasing unreferenced resources, but script can still be triggered on the worklet thread through BaseAudioContext.audioWorklet.addModule().

Making AudioContext.close() also close MessagePorts could be a breaking change for any clients that, for example, might collect statistics after AudioContext.close(). If Chrome has always done this, however, then perhaps that might not be a problem. I wonder what Chrome does to the MessagePorts and what it does when addModule() is called. I think I'd prefer something explicit over having messages queue but never run because the event loop stops processing them.

The worklet's lifetime is explicitly terminated only when "destroying the Document". Worklet has some provision for user agents choosing to terminate, but AudioWorkletGlobalScope forbids: AudioWorkletGlobalScopes must not be terminated arbitrarily by the user agent. Worklets may of course be garbage collected if content scripts no longer have access or cannot be triggered.

If the AudioWorkletGlobalScope were terminated, addModule would create another. This would have no references to the previous Wasm module, unless the previously added modules somehow can obtain a reference again.

I'm not familiar enough with Wasm to fully understand the requirements and when this becomes an issue. Would similar issues apply to other Worklet types or is this problem specific to AudioWorklet because it allows communication through MessagePort?

I'm not clear how Worker.terminate() would be useful for this purpose, given that it runs in parallel and I don't see any notification of completion. I'm not familiar with the history or purpose of this method.

from web-audio-api.

Would similar issues apply to other Worklet types or is this problem specific to AudioWorklet because it allows communication through MessagePort?

I'm not familiar enough with other worklet types, but I think it would indeed apply to any worklet type.

I'm not clear how Worker.terminate() would be useful for this purpose, given that it runs in parallel and I don't see any notification of completion. I'm not familiar with the history or purpose of this method.

Indeed Worker.terminate() is not immediate and there is no notification of completion AFAIK. But workers can be prevented from running anything by just blocking indefinitely with Atomics.wait(), which can't be done with worklets as they don't support blocking.

The worklet's lifetime is explicitly terminated only when "destroying the Document". Worklet has some provision for user agents choosing to terminate, but AudioWorkletGlobalScope forbids: AudioWorkletGlobalScopes must not be terminated arbitrarily by the user agent.

I think this resolves the clarification issue! Thank you for finding it for me.

Currently audio worklets are not garbage collected in any browser (Chrome, Firefox, Safari) when a sufficiently complex Wasm module is instantiated in them, even after dropping all references to JS values. I assume it is difficult to determine if the Wasm module could execute any code (e.g. Atomics.waitAsync() could be used to wake up and run code at any time, or a FinalizationRegistry could be used to call into the module when something is garbage collected).

I confirmed in Chrome and Firefox that without a Wasm module audio worklets are successfully garbage collected and it can be detected by using FinalizationRegistry.

In conclusion the closed state can't be used to solve this problem.

from web-audio-api.

Thanks both for the discussion! FWIW, I agree with @karlt's response.

from web-audio-api.