-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zombie process #1566
Comments
From the graph, it looks like the parent process is still running? To me, a zombie process means one where the child continues without exiting even after the parent exits. Using the JS esbuild API starts a long-lived child process for the rest of the session that is reused for future JS API calls. So what you are showing appears to be expected behavior. |
Yep, parent process is running, but inside worker I called Calling If this is expected behavior - how I can stop |
That does sounds like a zombie process then. Can you provide instructions for how to replicate your situation (or provide some code to demonstrate the issue)? |
Yep, I will make a repro code for you |
Sorry for delay. |
After some investigation the problem appears to be that in node, ending a worker thread means any child processes created by that thread turn into a zombie process when they die. I believe this means that node isn't reading the exit status of the process so the OS is keeping the process table entry around until it does. I think this is maybe a bug in node? At least there doesn't seem to be anything I can do about this on my end. Things I tried:
I think this may mean that node requires at least one full turn of the event loop in between the call to However, there's really no reason you need to be using worker threads like this. It's likely both slower and less efficient than just calling esbuild's API directly. The underlying implementation uses Go and already spreads the work out over all available CPU cores. Using worker threads to call esbuild's API like this is very inefficient because it means every build involves spawning a new JS VM, a new child process (which can be quite slow on some OSes), and creating two new additional GC threads (since JS and Go both have multi-threaded GCs). All of that extra CPU and memory usage is avoided by just calling esbuild's API directly. So I recommend avoiding this issue by just removing the worker entirely. |
Thank you for so detailed answer! |
Hi!
In my project I'm using esbuild inside worker_threads. In watch mode worker starts on external file change (I'm using chokidar).
On macOS 11.5.2 I noticed that esbuild process becomes a zombie after successfull build.
Also I found some similar issue - #643
The text was updated successfully, but these errors were encountered: