mach implementation needs to break large messages into pieces

[jdm]

servo/servo#13054 and servo/servo#10390 demonstrate clear cases where mach imposes size limits on the messages sent. We should break messages that exceed these limits into pieces and reconstruct them on the receiver's end.

[antrik]

I just glanced over the code quickly, so I'm not entirely sure: but it looks like all the data is transferred in-line. There is no need to split up anything: just make sure large data blocks are transferred out-of-line instead. This avoids any size restrictions, saves memory (I think), and it's even faster on some architectures. (Not on x86 though AIUI, unless using large pages I guess...)

[antrik]

Also, this problem can be worked around by not sending possibly very large things in the message directly, but rather setting up a shared memory region instead -- that's effectively the same as doing an out-of-line transfer on Mach.

The downside is that it's much more complicated to use. OTOH, it avoids the need to do serialisation when not strictly necessary, so it might potentially increase performance significantly.

It might be worth considering to use shared memory transparently for large messages in the platform-independent part of ipc-channel. This would allow simpler platform backends, as they would need no special handling for large messages this way...

[antrik]

Summing up, I see three distinct ways to address this problem:

1. Use out-of-line transfers in the macos backend.
2. Transparently use shared memory for large transfers, in a platform-independent fashion.
3. Punt to the caller -- the caller explicitly needs to use shared memory for transfers that might get very large.

Variant 2. is the most involved in terms of code changes, but might be the best approach in the long run -- not sure. 1. or 3. are easier short-term solutions, each with different trade-offs.