Is it intentional to not expose AbortSignal to Worklets?

[saschanaz]

A worklet has EventTarget#addEventListener but it cannot use AbortSignal to batch-remove them. Is this intentional?

[annevk]

I guess we should add this to AudioWorklet as well then.

cc @padenot

[padenot]

We probably can use this in a few places indeed.

@hoch, I'm thinking about OfflineAudioContext rendering cancellation, decodeAudioData, etc. Unclear for AudioWorklet, maybe it can be useful.

[hoch]

Interesting. How one would associate an AbortController with OfflineAudioContext.startRendering() and BaseAudioContext.decodeAudioData()?

Like @padenot mentioned, I am also not sure what this means to non-main thread Worklets.

[annevk]

I don't see Paul mentioning that? In any event, given that we expose events in audio worklets, it seems we should expose this as otherwise addEventListener() is less functional in audio worklets and that would be confusing.

(If you want other APIs to adopt this as well, typically you would make them accept a dictionary with a signal member, as addEventListener() and fetch() do, for instance.)

[hoch]

I was simply agreeing to the comment "Unclear for AudioWorklet".

Thanks for the explanation, @annevk!