These stray EPIPE messages have been a problem for a while now, especially
on Windows.
In most cases, they appear to stem from sending a message to a process
that is about to exit, such that the message races against the exit, and
sometimes loses. When that message is a just an obligatory response to a
final message from the exiting process, the exiting process probably does
not care about (and will not receive) the response, so we can safely
swallow the EPIPE error.
Now that all otherProcess.send calls have a callback function, I'm hopeful
we will never see EPIPE errors again.
Fixes#10073, per
https://github.com/meteor/meteor/issues/10073#issuecomment-405290391
While thinking about this bug, I realized that sending IPC messages to
specific packages in the server process was much less flexible than
sending messages based on an arbitrary topic string, since the topic
string approach allows both `autoupdate` and `dynamic-import` to listen
for the same message.
The topic string approach calls for a listener interface like
`onMessage(topic, callback)`, which elegantly replaces the previous
approach of requiring packages to export a single `onMessage` function.
However, because the `meteor` package does not have access to the module
system, implementing the `onMessage` listener interface in the `meteor`
package would have required exposing an API like `Meteor.onMessage(topic,
callback)`, which has an unpleasant global smell to it. Instead, the
`onMessage` function should be explicitly imported (using the module
system) from a less-generically-named package.
Since I knew I was going to have to move the message dispatch logic out of
the `meteor` package, I decided to create a new package called
`inter-process-messaging` to implement the parent/child components of the
IPC system.
