How to find out if there are more events registered in the event loop (bonus: how much)

Question

I am trying to write a Node.js program to execute and monitor javascript programs. I am looking for a way to find out if a monitored program continues to "work", i.e. Do something useful.

In my current approach, when I get the code for testing, I start a new child process and pass the code to it. In the child process, the code creates a Sandbox using Contextify and executes the code using this sandbox.

After returning the call to sandbox.run(code) I know that the blocking part of the code is finished and can show it in the user interface. However, now I do not know if the code registered any timers using setTimeouts, or created other event sources that could lead to parts of the code being displayed later. Therefore, I do not know if this is really “finished”.

Is there a way in Node.js to check if there are more events in the event loop to handle (or even better how much is left)?

I found this other question , but it only talks about how to track the event loop to find out if node performance is all. But I'm not interested in performance (I don’t care that the executable code blocks for 10 seconds or just does something in 1 ms every 2 minutes), and I don’t want to use external tools, but I learn about the status of the event loop from inside the node. Is it possible?

Answer 1

I solved my problem in a way, although I did not find a general answer to the question.

The idea here is that the process will exit on its own if it has executed all the code from which it was run and no EventEmitters are already registered. This was basically what I wanted, since I wanted to be notified when the process was "done" and now I can just listen to the "exit" child_process event.

But my process, which executed the code, did not exit on its own. This had two reasons:

• I used a timer to regularly send collected execution data to the parent process. If such a timer is registered, the process will not exit. You could have unref a timer, but I was afraid that this would result in data loss, since the process might exit before the last bit of data was sent (because it did not wait for the timer to complete). Therefore, I changed my code to only schedule a timer if data was sent, instead of regularly checking the data being sent.
• I used fork to create a child process. This also creates a communication channel between the parent and child process, and since I needed to send the code to be executed by the child process, I registered the child process for messages received from the parent using process.on("message", callback) . However, we now have another registered EventEmitter that prevents the process from exiting the game. Fortunately, I realized that I only need one message from the parent process and no additional messages so that I can delete the event emitter after receiving this message. Therefore, instead of process.on() I used process.once() , which will call back only once and automatically delete the event emitter after that. Exactly what I wanted. Alternatively, you can use process.removeListener() .

Now I just wait for child_process to exit and thus find out that everything is over and can notify the client.

So, the solution here is to make sure that none of your own EventEmitters supports this process, and then just waits for it to exit.