emscripten global handling of onmessages causes conflicts with other apps

[vladmandic]

emscripten registers a global message handler on initialization,
so if any other js app uses messages, it will result in errors being printed constantly

worker.js received unknown command

root cause is https://github.com/emscripten-core/emscripten/blob/main/src/worker.js#L288

pr #16450 fixed this exact issue for library_pthread.js,
but same (or similar) fix should be done for worker.js as the code flow there is nearly identical

environment: emscripten 3.1.20 on chrome 104

link to issue in tensorflow/js exposed due to this: tensorflow/tfjs#6687

[sbc100]

What kind of events are seeing show up in the onmesage handler in the worker? i..e how are you sending these messages to your worker? Are you calling postMessage from another worker something else?

[vladmandic]

@sbc100 message is sent using postMessage and it can be sent in either main context or a webworker.
actual tfjs code that causes emscripten to start printing error messages is:

const messageName = 'setTimeoutWPM';
  let fns: Function[] = [];
  let handledMessageCount = 0;

  // If the setTimeout nesting level is greater than 5 and timeout is less than
  // 4ms, timeout will be clamped to 4ms, which hurts the perf. Interleaving
  // window.postMessage and setTimeout will trick the browser and avoid the
  // clamp.
  const setTimeoutWPM = function(fn: Function, timeout: number) {
    fns.push(fn);
    setTimeout(() => {
      window.postMessage({name: messageName, index: fns.length - 1}, '*');
    }, timeout);
  };

in either case, emscripten should not expect that all messages are intended just for emscripten - that is bad assumption to start with. and that was fixed for library_pthread.js, so same should be fixed for worker.js.

[sbc100]

I think the difference is is that emscripten workers are dedicated to running pthreads... I guess we can look at them as kind of an implementation detail of the thread itself (for example there is not really any API for get a handle to the a worker from the outside).

A followup question: Is the above code run on a worker? Does window.postMessage work on a worker? From the docs it looks like the windoe object corresponds to the worker itself? So this is like sending a message to its own message loop? This does seem like perhaps a legitimate thing to do.

I think we have had previous discussions about allowing users to use the event loop like this for custom messages.. let me see if I can dig some of them up.

BTW, how do you inject the corresponding message handler? Do you use window.addEventListener?

[sbc100]

Looks like maybe a dup of #15278?

[sbc100]

OK, I think I'm convinced enough that we shouldn't be error'ing out when folks do addEventListener + postMessage in a worker. I think we should add this, along with test that shows it working. If anyone has time to look into doing this feel free to send a PR.

[vladmandic]

@sbc100 i've created a pr #17850