-
Notifications
You must be signed in to change notification settings - Fork 30k
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
child_process: special handling of process.on('message') #13913
Comments
-1 That would unnecessarily break backwards compatibility for zero gain IMHO. |
@mscdex I mean emit both events (with proper checks). Should not break break compatibility, and allow for an opt-in stricter/guaranteed means of IPC. |
@refack but couldn't some evil actor just emit IPCMessage
in my code, I check for properties on the message object coming back to see if it's IPC related. |
As I see it the |
I still don't see any worthwhile gain coming from such changes. |
(removing "good first contribution" tag as there isn't yet a consensus) |
Also -1. Adds complexity and overhead for unclear benefit and feels a bit like a solution in search of a problem. |
Closing for lack of consensus 🤷♂️ |
has a special meaning in the context of IPC between parent and child. The problem is a
'message'
event could be triggered other code, or listened to outside of IPC context, so we can not do any special treatment for it.I suggest adding
'IPCMessage'
that only the IPC channel can trigger, and registering a listener to would fail if an IPC channel was not established.Ref: nodejs/help#693 (comment)
[edit]
The intention is to emit both events:
message
for backwards compatibility, andIPCMessage
for a validated IPC only events.The text was updated successfully, but these errors were encountered: