Daniel Ehrenberg

OK, let's get more input from JSC, but this seems like part of what should go into V1 either way we decide.

We discussed this change in the WebAssembly WG meeting on April 19th, and my understanding is that it had consensus, to continue permitting the flexibility. Should we land this patch?

The meeting date was clearly a typo. I've pushed a rebase. I can't find any meeting notes which refer to this PR. Maybe we should discuss it in the future....

In [a later WebAssembly CG meeting](https://github.com/WebAssembly/meetings/blob/master/2018/CG-09-18.md), we discussed this issue further, with the suggestion to *always* take an event loop turn, even if it's not necessary, for consistency across platforms....

I've pushed a patch to make the change as described in https://github.com/WebAssembly/spec/pull/745#issuecomment-434645244 of including an event loop turn unconditionally for asynchronous instantiation. This is important to get right, partly because...

@Ms2ger You've incrementally landed many parts of this PR. Would you be interested in rebasing it?

@kmiller68, @tschneidereit and I have been discussing the semantics here. With this PR, each time a WebAssembly module is instantiated, there would be an event loop turn, in order to...

I worded that a bit clumsily; I meant more like, *if* we expect that, then that would be one story for why not to worry about this impact/alignment with JS.

To clarify, no one here is talking about spinning the event loop. Instead, instantiating a WebAssembly module would, in this patch, have the possibility to do asynchronous work (e.g., compilation...

@smaug---- Nothing in this PR would affect when the loaded event fires, because loading a WebAssembly module does not relate to that event. WebAssembly is loaded with APIs like [instantiateStreaming](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming#Examples),...