Atomic.waitAsync never wakes

[ronag]

See repro https://github.com/ronag/waitAsync-wake-repro

Seems like Atomic.waitAsync sometimes never wakes, even if provided with a timeout.

[ronag]

Not sure if a node workers or V8 atomics issue. @nodejs/workers @nodejs/v8

[ronag]

It seems like the worker dies while waiting for atomics?

[ronag]

It's not that it doesn't wake, it's that it stop running. If I add a setInterval in the worker then everything works.

[Jamesernator]

I had a little play around, the reason this is happening is because nothing is keeping the thread alive. Usually for a worker_thread having:

import { parentPort } from "node:worker_threads";

parentPort.on("message", () => { /* ... */ });

would keep the worker alive because parentPort would have it's .hasRef() set to true which tells Node to keep the thread alive even if there are no pending events on the event loop stack.

This is why setInterval keeps your thread alive, basically setInterval adds a ref to the thread so that it'll stay alive enough though the microtask queue is empty (as does any IO like fs.promises.readFile() or whatever).

There is in fact already an open pr to make Atomics.waitAsync ref the thread as well, so your issue here will be fixed by that.

In the meantime just use parentPort.ref() to keep the thread alive indefinitely (and parentPort.unref() when you're done).

[joyeecheung]

We were actually wondering if it is necessary for the host to keep the thread alive for the timeout in https://bugs.chromium.org/p/v8/issues/detail?id=13238 (this is not specified and host-defined, so technically Node.js does not have to keep the thread alive - i.e. this would be a wontfix). If you have a use case that cannot be solved by the manually reffing/unreffing solution mentioned above, or that can be error-prone with the manual solution, it would be appreciated to drop a comment in the V8 issue about the use case (the feature is still in stage 3 and it would be good to have a bit more investigation into this issue).

[ronag]

@Jamesernator suggestion works for us. I'll leave this open for a little bit for visibility but feel free to close it.

[Jamesernator]

or that can be error-prone with the manual solution

I think it's certainly surprising given that this is the only async operation that doesn't keep the thread alive. If anyone else does a similar pattern to the original problem here, i.e. use workerData but not parentPort then they're likely to hit this.

Even if v8 doesn't change anything, it might be sufficient just to put some documentation in worker_threads docs specifically about Atomics.waitAsync not keeping the thread alive by itself. Then if people do hit such an issue, they can just search that page for Atomics.waitAsync and will find that it doesn't keep the thread alive. (And ideally search engines will notice Atomics.waitAsync and worker_threads on the same page and direct people to it for similar queries).

[ronag]

Closing in favor of #44409