• Version: 11.7.0
• Platform: Linux threadripper 4.15.0-43-generic Tracking / Assuring Compatibility #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
• Subsystem: worker_threads

I am playing with node's worker_threads, running Emscripten-generated multi-threaded code in this way. From what I can see, the worker's

parentPort.on("message", function(msg) {
...
});

will not get triggered, if the main thread calls worker.postMessage(...) without "unwinding the stack" (ie., returning control to node's event loop). Unfortunately, this is exactly the kind of code that Emscripten generates: the main thread will use Atomics.wait(...) to wait for its child threads (workers) to complete, but it will not actually return control to node.

Note that the Worker.postMessage(...) semantics is insofar different from how postMessage works in browsers, which gets executed immediately, ie., WITHOUT returning control to the browser.

This may be related to #21417.