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
So I guess this is more of a discussion rather than an "issue" (more a feature request).
When forking, an IPC channel is created and there are two options of serialising the data that gets sent: the standard, default, json, or the more "internal" option of advanced. The problem is, it's highly likely that people will come across the need to serialise custom data types (think complex classes) and as such, another layer of serialization needs to occur: JSON.[parse, stringify] at both ends of the IPC channel, to be able to hook into the replacer and reviver functions.
There's probably no immediate downside (but you've probably noticed it anyway): what happens if there's a lot of custom/complex data structures that need to be sent? You're essentially running two JSON.stringifys and two JSON.parses on each end of the IPC channel to 1) wrap your custom types, and 2) wrap the types again for the channel. This can cause a perfomance problem, not to mention that many forking scripts will need to make sure to implement custom serialization functions. The latter is somewhat trivial because you can just require the functions from somewhere and just use them, but it's the "just use them" part where people will hit the ID-10-T errors.
I'd suggest the enhancement to be that devs can specify their own serialization function where they need to convert objects into strings/buffers/streams (however it works internally), as well as their own deserialization function to does the same in reverse. For the most part, I expect these functions to be identical to the JSON parse and stringify functions, but with their own replacers and revivers - perhaps instead of that, devs only need to specify the replacers and revivers?
The only roadblock to implementation would be making sure the child process knows to use these custom functions... Perhaps instead of "sharing" the functions through the IPC channel, each script involved in messaging would have to call something like process.setSerialisingFunctions(ser,des) - but then again, we rely on ourselves to remember to run these functions.
I think this solution is more beneficial than not - but I guess it's not a pressing issue, because I seem to be the only one talking about it? 🤷♂️
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
So I guess this is more of a discussion rather than an "issue" (more a feature request).
When
fork
ing, an IPC channel is created and there are two options of serialising the data that gets sent: the standard, default,json
, or the more "internal" option ofadvanced
. The problem is, it's highly likely that people will come across the need to serialise custom data types (think complex classes) and as such, another layer of serialization needs to occur:JSON.[parse, stringify]
at both ends of the IPC channel, to be able to hook into thereplacer
andreviver
functions.There's probably no immediate downside (but you've probably noticed it anyway): what happens if there's a lot of custom/complex data structures that need to be sent? You're essentially running two
JSON.stringify
s and twoJSON.parse
s on each end of the IPC channel to 1) wrap your custom types, and 2) wrap the types again for the channel. This can cause a perfomance problem, not to mention that manyfork
ing scripts will need to make sure to implement custom serialization functions. The latter is somewhat trivial because you can justrequire
the functions from somewhere and just use them, but it's the "just use them" part where people will hit the ID-10-T errors.I'd suggest the enhancement to be that devs can specify their own serialization function where they need to convert objects into strings/buffers/streams (however it works internally), as well as their own deserialization function to does the same in reverse. For the most part, I expect these functions to be identical to the JSON
parse
andstringify
functions, but with their own replacers and revivers - perhaps instead of that, devs only need to specify the replacers and revivers?The only roadblock to implementation would be making sure the child process knows to use these custom functions... Perhaps instead of "sharing" the functions through the IPC channel, each script involved in messaging would have to call something like
process.setSerialisingFunctions(ser,des)
- but then again, we rely on ourselves to remember to run these functions.I think this solution is more beneficial than not - but I guess it's not a pressing issue, because I seem to be the only one talking about it? 🤷♂️
What's everyone else's thoughts?
Beta Was this translation helpful? Give feedback.
All reactions