Atomics.wait prevents postMessage being queued

[bmeck]

• Version: v11.0.0-pre
• Platform: OSX
• Subsystem: worker_threads

It appears that workers don't get sent messages if the sending thread uses Atomics.wait to block the thread sending the message.

// main.mjs
import worker from 'worker_threads';
const child = new worker.Worker(new URL('./worker.js', import.meta.url).pathname);
const shared = new Int32Array(new SharedArrayBuffer(4));
child.postMessage({shared});

// removing the following line allows {shared} to be passed to the worker
Atomics.wait(shared, 0, 0);

// worker.js
const {parentPort} = require('worker_threads');
parentPort.on('message', ({shared}) => {
  // never gets here
  console.log('worker got message', shared);
  Atomics.wake(shared, 0);
});

[benjamingr]

I'm not entirely sure this isn't the behaviour I'd expect.

To be clear - you're doing this to prevent access to the ShardArrayBuffer while it is being moved around?

[bmeck]

@benjamingr in the reduced example above, the main thread should wait on the SharedArrayBuffer being notified that it should wake anyone waiting on it. The shared is posted to the worker prior to wait being called on the main thread. The worker never receives shared.

[addaleax]

Okay, looked into it a bit, and the workers thing is a red herring here. Minimal reproduction:

$ echo "console.log('hi')" > foo.js && node --experimental-modules foo.js
(node:14413) ExperimentalWarning: The ESM module loader is experimental.
    at startup (internal/bootstrap/node.js:147:17)
    at bootstrapNodeJSCore (internal/bootstrap/node.js:600:3)

i.e. the main script just doesn’t get executed if it’s file extension is .js.

(In your original example, Atomics.wait() blocks forever because the worker thread doesn’t even get the chance to attach a message handler in the first place.)

[bmeck]

@addaleax my main script is using .mjs I'm not sure what you mean here. Are you stating that posting to workers is unsafe due to dropped events before they finish loading?

[addaleax]

@bmeck Try the example in the last comment, I think that it explains the issue better than words can

Are you stating that posting to workers is unsafe due to dropped events before they finish loading?

No – I’m saying it has nothing to do with workers

[bmeck]

@addaleax I don't understand .

[addaleax]

@bmeck If you create a script called foo.js, and its only contents are console.log('hi'), then:

• node foo.js prints hi
• node --experimental-modules foo.js does not print hi, it doesn’t actually run the main script if its extension is .js

[bmeck]

Are you saying that is related to new Worker('/path/to/foo.js')?

I am running node --experimental-modules --experimental-worker ./main.mjs which has main.mjs certainly logging out that it posted the message.

[bmeck]

I can get the worker to log as well if I remove the line in question above.

[addaleax]

I think we’re seeing different things because the recently landed 8ee604c caused a regression in ESM that may be masking other issues :/ Will open a revert PR, then dig into it again

[devsnek]

@addaleax there's already a pr to fix it: #21350

[addaleax]

@devsnek Can you land that? It seems like we should still revert the original patch asap if we can’t do that now?

[addaleax]

Okay, but with that patch applied I can’t reproduce the original problem here anymore … @bmeck Can you share the SHA you’ve built Node for?

[bmeck]

I'm running a fork of 31d5bde on https://github.com/bmeck/node/tree/service-loader/ I haven't written anything to change the Worker code. let me try and rebase to latest today.

[bmeck]

I can no longer reproduce this on new builds, closing . https://gist.github.com/bmeck/fb90b23234aee41f392d4a19b61ba6eb is my more complete reduced test for this working properly