Synchronous return can't be accurately polyfilled

[ninevra]

Since #30, the proposal spec requires that Atomics.waitAsync() return synchronously. This doesn't appear to be possible for polyfills that use a pool of Workers and Atomics.wait(), for a few reasons:

• There's no way for the polyfill to know when the worker has begun to wait, so it may miss some notify()s that happen between returning and actually waiting. The spec appears to require that the waiter be added to the waiterlist synchronously & before returning.
• The worker might get 'not-equal' when it calls Atomics.wait(), but has no way of synchronously communicating this to the polyfill. The spec doesn't appear to allow resolving the returned promise to 'not-equal'.

polyfill.js hasn't been updated to the post-#30 semantics; possibly PROPOSAL.md could be updated to clarify that Atomics.waitAsync() can't be accurately polyfilled?

(Forgive me if this is incorrect / already known / not of concern. I couldn't find any prior discussion of the impact on polyfills.)

[syg]

Thanks for reporting this issue. I agree with your analysis and think you're right that the "fail fast synchronously" semantics cannot be accurately polyfilled using Atomics.wait given the inability to atomically know if a wait was successfully started.

The polyfill is not maintained at all, I'll update the readme to reflect that it is of historical interest only, and that an accurate polyfill is not possible on the web without sync communication to the main thread.