• 15 October 2025
• IpcChannelMultiplexing

About three months ago, I posted IPC channel multiplexing: next steps. Since then I’ve taken a complete break from the project to make the most of the summer and to go on holiday. As I consider how to proceed, I think those next steps still make sense, but that’s not the whole story.

The problem: file descriptor consumption

The basic problem the multiplexing prototype is trying to solve is as follows. If an IPC channel endpoint is sent over another IPC channel, when it is received, it consumes a file descriptor (at least on Unix variants). A new file descriptor is consumed even if the same IPC channel endpoint is received multiple times. This can crash the receiving process if it runs out of file descriptors.

Motivation

The thing that has changed in the intervening gap is my motivation.

I really enjoyed implementing multiplexing of IPC channels as it was relatively self-contained. Extending the API to support more Servo usecases does not feel so fun.

Also, I would like more assurance that if I invest the effort to make IPC channel multiplexing suitable for adoption by Servo, that there’s a reasonable chance it will actually be adopted.

Why might it not be adopted?

There seem to be relatively few Servo developers who understand IPC channel well enough to engage with adopting multiplexing. Plus they are likely to be very busy with other things. So there may simply be a lack of traction.

Also, multiplexing isn’t a simple piece of code, so merging it into IPC channel will increase the project’s size and complexity and therefore its maintenance cost.

There may be performance or usability issues in adopting multiplexing. I’m not aware of any such issues and I don’t anticipate these being significant if they crop up, but there’s still a risk.

Who to work with?

Currently, I’m working in isolation from the Servo team and I’d like some reassurance that the direction I’m heading in is likely to be adopted.

Pro’s and con’s

The advantages of continuing are:

• Capitalising on the effort already expended.[1]
• Potentially fixing the bug.
• Overcoming the difficulties involved would give a greater sense of achievement.
• I enjoy solving difficult problems and it would keep my brain active.

The disadvantages of continuing are:

• Potentially wasting more effort.
• Now may be an opportunity to retire properly from my career in software development.[2]

On balance, I think I’ll continue.

Packaging

It would be possible to move the multiplexing prototype to a separate repository and crate which on the IPC channel crate.

The advantages of this are:

• It could increase the profile of the prototype.
• I could host this on codeberg.org rather than github.com[3]
• Ease of code navigation, since the code would be pure Rust rather than multiplatform.
• Ease of CI: Linux only.
• Ease of promotion of changes, since it wouldn’t require the involvement of IPC channel committers.
• Publication to crates.io for ease of consumption by Servo.[4]
• Documentation could be centred on multiplexing.

One possible disadvantage is that it would not be possible to reuse IPC channel internals. For example, if one of the missing features for multiplexing was essentially the same as that for vanilla IPC channel, I couldn’t just generalise the code and share it.

What next?

I think the most effective way forward is to test the Servo team’s willingness to adopt multiplexing by focussing on a usecase that is known to exhibit the bug, reproducing the bug in isolation, showing that multiplexing fixes the bug, and proposing a fix for Servo.

So I’ll start by looking at the bug reports, picking one, and looking at the IPC channel usecase in Servo which hits the bug. I’ll defer the decision of whether to package the prototype as a separate repository until I start to touch the prototype code again.

---

This is contrary to the sunk cost fallacy. ↩︎ 1.

I’m not sure what else I would prefer to do with my spare mental capacity. ↩︎ 1.

I really dislike Microsoft’s policy of trawling github.com to build AI models. I’m also shocked about Microsoft’s willingness to create e-waste by dead-ending Windows 10 and not supporting older hardware with Windows 11, although they have delayed the deadline with the Windows 10 Extended Security Updates (ESU) programme. (On the other hand, maybe this move will push more people to adopt Linux. See END OF 10.) ↩︎ 1.

Unfortunately, and it’s a big unfortunately, this still requires the repository to be mirrored to github.com. See Non-Github account creation. ↩︎

• ← Previous Metrics