IPC channel multiplexer

• 01 November 2025
• IpcChannelMultiplexing

Although more implementation is needed before IPC channel multiplexing is ready to be applied to Servo, I have been mulling over two questions:

1. How should the multiplexing code be packaged?
2. When is multiplexing likely to benefit Servo?

Packaging

As described in an earlier post there are a number of advantages to packaging the multiplexing code as a separate repository and crate.

However, since writing that post, one other advantage became clear. IPC channel was changed to depend on serde-core rather than serde, to speed up certain build times. But the multiplexing prototype currently requires serde (to derive some serialisation and deserialisation code) rather than serde-core. Moving multiplexing to a separate repository and crate would allow it to continue to depend on serde.

There were some alternatives:

• Revert the change in the multiplex branch of (my fork of) the IPC channel repository. The downside of this is that rebasing the branch would then be more sensitive to upstream changes.
• Implement serialisation and deserialisation manually rather than deriving the implementation. But I don’t see much of an advantage to doing that at this stage.

More generally, changes to the internals of IPC channel would not impact the multiplexing code if it was moved to a separate repository.

So I bit the bullet and created ipc-channel-mux (mux being a common abbreviation for “multiplexer”). See the README for an up to date list of advantages of this packaging.

When would multiplexing be beneficial?

In short, multiplexing would be beneficial to Servo when multiple subchannels are multiplexed over a single IPC channel or when multiple subsenders are transmitted over a subchannel, especially where IPC channels are known to crash a process on Unix variants by exhausting the process’s available file descriptors.

For details, see When is multiplexing beneficial? in the README of the new repository.

Conclusion

It only took a few hours to split out the new repo. I have yet to publish a crate and I’m hesitating because publishing a crate is irreversible and I doubt anyone wants to consume the code yet. Update: see the postscript.

Acknowledgements

Kudos to the developers of:

• https://github.com/newren/git-filter-repo which proved extremely useful in splitting out the multiplexing prototype into its own repository while preserving git history. (That’s why some files are 10 years old according to their history.)
• https://github.com/est31/cargo-udeps which helped me find and delete unused dependencies in the new repository.

Postscript

I bit the bullet and published an initial version of the crate. “Release early, release often” as they say.

• ← Previous
  
• Next →
  Dead code