3 ms·
The two main reasons I know/care about (there may be more) are that it can be much faster (zero copy, reduced context switches) and also guarantee the message i
by lathiat 10y ago
The two main reasons I know/care about (there may be more) are that it can be much faster (zero copy, reduced context switches) and also guarantee the message isn't changed while reading (by sealing the originating buffer).
The last is something you need kernel help to enforce.
- qwertyuiop924 10y agoYeah, but is it worth the cost? I would say no.
- saynsedit 10y agoThere's no case for this usually marginal speed benefit. Most programs are dealing with vastly slower bottlenecks. Like network or disk latency. IPC latency is so far down the list of priorities in terms of things to optimize. Not to mention that regular user-kernel-user buffer copying is plenty fast now, especially since the buffers will likely be cache-resident. Zero-copy is mostly hype without performance numbers to back it up. Don't need this complex message sealing mechanism.
- dooglius 10y agoI don't see anything described that can't be done in a userspace library through shared memory. Maybe security is a concern, where we don't trust some nodes that might be exploited not to be able to screw with the shared memory? But then zero-copy would be off the table for the same reasons, no?