Repository navigation
child_process: special handling of process.on('message') #13913
Description
- Version: *
- Platform: *
- Subsystem: child_process
process.on('message');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, and IPCMessage for a validated IPC only events.
Activity
mscdex commentedon Jun 25, 2017
-1 That would unnecessarily break backwards compatibility for zero gain IMHO.
refack commentedon Jun 25, 2017
@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.
ORESoftware commentedon Jun 26, 2017
@refack but couldn't some evil actor just emit IPCMessage
process.emit('IPCMessage')even if it were not an IPC message?in my code, I check for properties on the message object coming back to see if it's IPC related.
refack commentedon Jun 26, 2017
As I see it the
nodeinternal code will have exclusivity on emittingIPCMessage. Probably need to inherit fromEventEmitterand override theemitand theregisterListenerdo validateIPCMessageevents.A really "evil actor" could probably monkey patch something, but that is true for most of the API, sometimes for the better (i.e.
graceful-fs)mscdex commentedon Jun 26, 2017
I still don't see any worthwhile gain coming from such changes.
TimothyGu commentedon Jun 26, 2017
(removing "good first contribution" tag as there isn't yet a consensus)
bnoordhuis commentedon Jun 26, 2017
Also -1. Adds complexity and overhead for unclear benefit and feels a bit like a solution in search of a problem.
refack commentedon Jun 26, 2017
Closing for lack of consensus 🤷♂️