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
I have a non-server Node.js application that forks N child_processes (sometimes 50+ child processes), before the child processes exit, process.send is called to send a message the parent process, the problem is there seems to be no way to guarantee that the IPC message gets sent to the parent before the child process exits.
I am pretty certain that process.send is now async. I am 99% certain that the above is accurate, because I have done extensive logging in both the child processes and parent process to verify.
process.send takes a callback, like so:
process.send({some:'message'},function(err){// this gets fired, but the parent process hasn't not necessarily received the message?});
my minor complaint is that the above callback does not seem to be meaningful - there is no response from the parent process, so the fact that the callback fires actually seems to signify very little, but normally error-first callbacks like this would signify some sort of success.
so my question is, if core IPC in Node.js is async, could the callback above be made more meaningful, so that it only fires if the parent has received the message?
If not it seems like some sort of request/reply protocol using ZMQ might be necessary, otherwise I can't prevent my child processes from exiting before the IPC messages actually get sent out.
The text was updated successfully, but these errors were encountered:
nevermind, you can probably close this, I just realized (duh) that I can create a request reply pattern with process.send/n.send, and I can wait for the reply message from the parent before calling process.exit() in the child process. Although if you could address my concern about the process.send callback that would be nice thanks all!
Yes, the API is a bit lacking here. The callback is called after the message has been sent but does not guarantee that the message has been received. Because of the async operation and the nature of the IPC channel, there's no way for us to know for certain that the message was received. The only way, as you indicate, is for the recipient to explicitly send and acknowledge response.
I am on Node versions 5.4 and 6.1
I have a non-server Node.js application that forks N child_processes (sometimes 50+ child processes), before the child processes exit, process.send is called to send a message the parent process, the problem is there seems to be no way to guarantee that the IPC message gets sent to the parent before the child process exits.
I am pretty certain that process.send is now async. I am 99% certain that the above is accurate, because I have done extensive logging in both the child processes and parent process to verify.
process.send takes a callback, like so:
my minor complaint is that the above callback does not seem to be meaningful - there is no response from the parent process, so the fact that the callback fires actually seems to signify very little, but normally error-first callbacks like this would signify some sort of success.
so my question is, if core IPC in Node.js is async, could the callback above be made more meaningful, so that it only fires if the parent has received the message?
If not it seems like some sort of request/reply protocol using ZMQ might be necessary, otherwise I can't prevent my child processes from exiting before the IPC messages actually get sent out.
The text was updated successfully, but these errors were encountered: