juj

> Do we want to keep emscripten-defaults in sync with llvm-defaults? My initial gut feeling is no - I expect they would be doing the decision based on even less...

> Emscripten has always unapologetically targeted JS engines first and foremost The reason for this is that when compiling to JS->asm.js->wasm was created, no other Wasm VMs like Wasmer existed....

> Should we remove this test (and the ability to using these spin locks within worklets)? Audio worklets definitely need to have support for spinlocking, and they should also have...

> I though the pthread API were all off limits in worklets becasue they are based on wasm workers, which don't support pthread API (even pthread_self doesn't work right?) Err,...

> 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.](https://github.com/emscripten-core/emscripten/blob/main/test/webaudio/audioworklet_emscripten_locks.c) Hmm, where does the spinlocking occur? Where...

> Would you also consider it valid for a lock to be held between event loop events? i.e. could I write spin_lock(); setTimeout(unlock); on the main thread? Technically, I would...

> @juj what do you think about adding this new API? Looks good to me. I would consider removing the `userData` part from the unregistration, and also this would be...

> Maybe we should at at least add a new generic API for this? i.e. if we also add a single API for registering callbacks then we could at least...

Given that this ticket #2212 discusses an opt-out, a general solution and is in the process of gathering user statistic, I opened a separate ticket to specifically discuss the narrower...

> This setting has been causing some problems (see #22188) so I think we should just remove it. I'm not sure if this is the best approach. Why drop useful...