search

servo / ipc-channel

A multiprocess drop-in replacement for Rust channels
Apache License 2.0
857 stars 129 forks source link

Consider multiplexing everything over one socket on Unix #97

Open pcwalton opened 8 years ago

pcwalton commented 8 years ago

I'm worried about the file descriptor limit being an ever-present failure mode. Chromium and Gecko multiplex everything over one socket, and I'm beginning to think we should too.

antrik commented 8 years ago

@pcwalton I tend to think this is only a serious problem when running in single-process mode. On platforms that do actual IPC (not inprocess), we should probably always run multi-process...

In the multi-process case, content processes should be fine, as they don't need connections to many other processes; and server processes such as the font cache should be fine, as they can serve all client on a single channel. The only problem might be the main processes, which orchestrates all the content processes in the current design AIUI, and thus probably has separate channels to each? If that is the case, we should probably consider solving this specific problem.

I'm not sure what you mean exactly by "multiplexing everything over one socket". Instead of having a separate socket for each IPC receiver, use only a single shared socket per process, and then have a multiplexer thread that distributes messages to the actual receivers (over mpsc channels I suppose) based on some kind of channel ID sent along with the messages?

If that is what you mean, my gut feeling is "please, no!" Aside from overhead and extra complexity in actual message transfer, creating channels or passing receivers would become very complex operations; we would need to manage the multiplexer thread; and worst of all, handle all the corner cases and avoid race conditions related to closing channels while transfers are in progress. If it's anything to go by, RPC cancellation is probably the darkest corner of the Hurd design.

I think we should avoid this at all costs, and keep IPC as simple as possible. Chromium has had several exploits based on vulnerabilities in the IPC code. If we can't trust this code to be totally reliable, that defeats one of the major reasons for doing multi-process in the first place... I'm already unhappy about the fragility of our linux IPC code as it is.