When a pthread fails initialisation the wrong error is thrown

[VirtualTim]

Unless I'm missing something, if Module['dynCall_ii'](e.data.start_routine, e.data.arg); (here) throws, Module['_emscripten_futex_wake'] (here) will be undefined. This means that whatever error was actually caught will never be re-thrown, and Module._emscripten_futex_wake is not a function will always be thrown instead.

In ideal situations this should of course never occur, but it does lead to some misleading errors during development/debugging.

I'm tempted to submit a PR just removing that _emscripten_futex_wake, because I'm not sure what value it adds. If this function call actually has a use I could just open a PR when the called is wrapped in a if (typeof(Module["_emscripten_futex_wake"]) === function) {...}

Thoughts?

[kripken]

I don't follow - why would Module._emscripten_futex_wake not be defined? That should be set up earlier, before running any code, I think, but maybe I'm missing something...

[VirtualTim]

It wont be defined inside a pthread if the pthread throws before the Module is finished initialising, right?

[kripken]

What do you mean by "initialiasing" here? Initializing the wasm module? If so, then yes, if that fails, then the exports from the module don't exist, but in that case nothing else can work either.

[VirtualTim]

Yeah that's what I mean. Obviously this is not something that should occur during regular use, but would make development easier as the originally thrown error would get lost.

I'll open a PR after Easter, that might make things clearer.

[VirtualTim]

For future reference the easiest way to reproduce this is via something like:

std::async(std::launch::async, [&]{
  exit(-1);
});