Stack overflow check broken when used with pthreads and embind in 2.0.3 onwards

[cwoffenden]

In 2.0.3 onwards when combining pthreads, --bind and -s STACK_OVERFLOW_CHECK=2 the stack check is failing for the workers (but is fine on the main thread). It's reproducible with one of the simpler pthread test files, for example:

emcc -s USE_PTHREADS=1 --bind -s STACK_OVERFLOW_CHECK=2 tests/pthread/test_pthread_create.cpp

Because the order of creation means embind is initialised before the stack checker, a false stack overflow is always generated from __embind_register_native_and_builtin_types() (since the limits are not yet inited).

This broke with changes in either #12095 or #12104 (more details to be added tomorrow if needed; we ran out of time today).

[tklajnscek]

I think the way to fix this is to move this:

// Embind must initialize itself on all threads, as it generates support JS.
Module['___embind_register_native_and_builtin_types']();

from library_pthread.js - initWorker to worker.js - onmessage -> if (e.data.cmd === 'run'), but passing in ignoreDuplicateRegistrations = true for it to work with thread pools... or just if it to only happen once.

I don't think any code should run before the stack check stuff is set up.

Does that sound reasonable?

[cwoffenden]

The alternative (though decidedly incorrect way) is to avoid native function calls in __embind_register_native_and_builtin_types() and call the JS ones directly, bypassing the stack check:

emscripten/system/lib/embind/bind.cpp

Line 100 in a534224

register_integer<char>("char");

Replacing the templated register_integer() with a macro to do the same (which @tklajnscek and I tried yesterday, and it works). The benefit to doing this (ignoring the code smell) is it doesn't change the order in which anything is run (for anyone/anything depending on it).