Errors related to async wasm instantiation should be more friendly

[dschuff]

If you try to call ccall/cwrap on a module before the wasm module is finished instantiating, you get an error that 'Runtime.stackSave' is not a function (cwrap itself of course can't work because the C function isn't there yet but stackSave is the first thing that will fail). I'd bet there's some module-level var that means "the wasm is instantiated or is still compiling" and we should query that it some of the obvious entry points like ccall to make that error friendlier, because this is likely to be a common issue.

[kripken]

When ASSERTIONS is on, we throw a message with

Assertion failed: you need to wait for the runtime to be ready (e.g. wait for main() to be called)

And we enable ASSERTIONS by default in unoptimized builds, so that hopefully helps most people. We could also add that check in builds without assertions, but it does add a little overhead and code size. If we think this is especially confusing though then perhaps we should do it.

[dschuff]

Ah I didn't realize that ASSERTIONS did that. That's probably sufficient.

…

On Wed, Jun 28, 2017 at 11:28 PM Alon Zakai ***@***.***> wrote: When ASSERTIONS is on, we throw a message with Assertion failed: you need to wait for the runtime to be ready (e.g. wait for main() to be called) And we enable ASSERTIONS by default in unoptimized builds, so that hopefully helps most people. We could also add that check in builds without assertions, but it does add a little overhead and code size. If we think this is especially confusing though then perhaps we should do it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#5346 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEiKG75eQUdWS7juJ4-4hwV_m58LjA-ks5sI0QcgaJpZM4OIsG6> .