Ingvar Stepanyan

Same can be reproduced with errors thrown by Babel parser: ```js > var code = 'x = @' undefined > try { parse(code) } catch (e) { var err =...

> assuming the semantics match. The semantics are slightly different - e.g. C++ wait actually verifies that the value has changed - but it should be still a pretty thin...

> I think the note about not waking up if the value hasn't changed only applies to spurious wakeups.) Hm I'm not sure about that bit. I thought it's more...

> Like, if something in Wasm performs (for whatever reason) manual `emscripten_atomic_notify` / its `__builtin_*` variant / its `Atomics.notify` JS variant on the address of `std::atomic` Those can probably count...

Thinking about it a bit more, you don't even need to use external wakeup to run into issues. Even via C++ APIs, if one thread does `atomic->notify_one();` then another waiting...

@shreyas-omkar Feel free to just submit a PR whenever you're ready.

Also running into this, the behaviour is particularly surprising when working with points. E.g. I'm trying to clamp a Point within image boundaries and getting: ```rust use nalgebra::SimdPartialOrd; type P...

I think having an official policy for both Wasm and untranspiled JS features would still be helpful. Something that is new since this issue had been raised - there are...

> In general Emscripten already has a robust and fine-grained feature/capability tracking (the -sMIN_x_VERSION system and code in feature_matrix.py), so the "Baseline " mechanism would be maybe a bit redundant...

> as this does not allow for the same type to be used by multiple tables. Not sure what you mean.