You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Only a single console.log is logged from a worker when exiting #40961
How often does it reproduce? Is there a required condition?
100% of the time.
What is the expected behavior?
I would expect to see
main
worker1
worker2
worker3
What do you see instead?
main
worker1
The main thread logged, but the worker only logged the first of three loggings.
Additional information
Somehow the first console.log is always logged out, but the other ones are stopped by the presence of the process.exit after them. This does not seem to be a race in my testing: the first one is always shown, and none of the others.
Returning to the main event loop after the first logging allows one more logging to show up. That is:
const{
Worker, isMainThread
}=require('worker_threads');if(isMainThread){console.log('main');constworker=newWorker(__filename,{});}else{console.log('worker1');setTimeout(()=>{// return to main event loop after first loggingconsole.log('worker2');console.log('worker3');process.exit(0);},0);}
That prints out worker2. Once more a single logging appears of all those that are expected to happen, and worker3 is not logged.
This was noticed in Emscripten here: emscripten-core/emscripten#14804 Emscripten will use process.exit when the program is done, and we were only getting the first console.log out of all those the program prints. (As a workaround we write synchonously to the fd for stdout, which does work.)
console.log() writes to stdout, which is an asynchrononous operation in Node.js (potentially also on the main thread, but always in worker threads). process.exit() exits synchronously, effectively aborting all currently ongoing asynchronous operations.
@RaisinTen Wouldn’t the interval also be a resource? 😉
I think in general the recommendation here should be to let workers finish naturally whenever possible instead of using process.exit(), or using synchronous operations when you need synchronous operations (e.g. using Atomics here).
I think in general the recommendation here should be to let workers finish naturally whenever possible instead of using process.exit(), or using synchronous operations when you need synchronous operations (e.g. using Atomics here).
Without this, it makes the use of logging to debug of multi-threaded programs very hard, because normal program stdout/stderr doesn't interleave as expected with log messages.
I think it stems from the use of worker_threads that don't yield to event loop. Its seems that consecutive console message to not reach the console while you not yielding.
This is very common in emscripten since workers that run pthreads normally never yield to the event loop.
The original reproducer seems to seems to be fixed in node v24 (but still fails in node v23). Do I guess this issue can be closed even though we don't know what the actual fix way? Maybe somebody could bisect, or we could just close this issue?
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
update comment with node issue (#15631)
targos commentedon Nov 25, 2021
@nodejs/workers
addaleax commentedon Nov 25, 2021
console.log()writes to stdout, which is an asynchrononous operation in Node.js (potentially also on the main thread, but always in worker threads).process.exit()exits synchronously, effectively aborting all currently ongoing asynchronous operations.RaisinTen commentedon Nov 25, 2021
When #40813 lands, you will be able to wait for the async operations to be over before exiting like this:
addaleax commentedon Nov 25, 2021
@RaisinTen Wouldn’t the interval also be a resource? 😉
I think in general the recommendation here should be to let workers finish naturally whenever possible instead of using
process.exit(), or using synchronous operations when you need synchronous operations (e.g. usingAtomicshere).RaisinTen commentedon Nov 25, 2021
@addaleax I don't think the
Immediatewould be an active resource when the callback is run 🤔:$ ./node test.js before [] after [ { type: 'TTYWrap', asyncId: 2, triggerAsyncId: 1 }, { type: 'Immediate', asyncId: 5, triggerAsyncId: 1 } ] during [ { type: 'TTYWrap', asyncId: 2, triggerAsyncId: 1 } ]👍
addaleax commentedon Nov 25, 2021
This is getting a bit off topic for this issue, but I'd consider that a bug.
kripken commentedon Nov 29, 2021
Thanks for the info @RaisinTen and @addaleax !
It's possible that with some work Emscripten can avoid calling
process.exit()from workers and instead leave that to the main thread.update comment with node issue (emscripten-core#15631)
sbc100 commentedon Jul 31, 2023
FWIW, we work around this in emscripten by using
fs.writeSyncwith1or2instead ofconsole.error/logto implement our logging functions: https://github.com/emscripten-core/emscripten/blob/995ba815a9ac62b1de2d45b5bbb4b796f051cddb/src/shell.js#L432-L443.Without this, it makes the use of logging to debug of multi-threaded programs very hard, because normal program stdout/stderr doesn't interleave as expected with log messages.
avivkeller commentedon Jul 2, 2024
Hey, is it known if the
process.exit()is the cause of this, or it worker threads in general (ref: #53701)sbc100 commentedon Jul 2, 2024
That looks like the same issue yes.
avivkeller commentedon Jul 3, 2024
I'm aware it looks like the same issue, but is
process.exitthe core of this issue, or is it theworker_threads.sbc100 commentedon Jul 3, 2024
I think it stems from the use of
worker_threadsthat don't yield to event loop. Its seems that consecutive console message to not reach the console while you not yielding.This is very common in emscripten since workers that run pthreads normally never yield to the event loop.
avivkeller commentedon Jul 3, 2024
Thanks for the insight!
sbc100 commentedon May 15, 2025
The original reproducer seems to seems to be fixed in node v24 (but still fails in node v23). Do I guess this issue can be closed even though we don't know what the actual fix way? Maybe somebody could bisect, or we could just close this issue?
github-actions commentedon Jun 25, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 26, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.