Can audio worklets pre-emptively interact with the main thread?

[sbc100]

We now have at least one test that assumes that the main thread can be interacted with via SAB with spinlocks: test/webaudio/audioworklet_emscripten_locks.c.

However there seem to be issues with it. See #24212 for example.

The larger question is: Is this kind of main-thread-interaction valid.

It practice that audio worklet is likely running on its own thread, but the spec says that might not always be the case: See https://html.spec.whatwg.org/multipage/worklets.html#worklets-motivations and note "Are thread-agnostic. That is, they are not designed to run on a dedicated separate thread, like each worker is. Implementations can run worklets wherever they choose (including on the main thread)."

Should we remove this test (and the ability to using these spin locks within worklets)?

[sbc100]

@juj @cwoffenden

[cwoffenden]

I wouldn't remove the ability for spinlocks in an AW, it's a valid use case and would force devs to bring their own. Originally this test was audioworklet_emscripten_futex_wake.cpp I and just fixed it (it's what started me down the rabbit hole of getting the audio tests to work in CI, since they passed regardless for years).

This has been running and passing until now, with a change in Chrome. I'll volunteer to change the thread interacted with to be a worker, which fulfils the spec and keeps working locks.