| |||||||||||||
Fast interprocess messagingFast interprocess messagingPosted Sep 16, 2010 8:35 UTC (Thu) by michaeljt (subscriber, #39183)Parent article: Fast interprocess messaging
That is nice for processes with the same owner of course, but a limited version for processes with different owners could be even nicer. For instance if it were possible for a process to open access to a section of its memory to, say, the process at the other end of a socket.
(Log in to post comments)
Fast interprocess messaging Posted Jan 6, 2012 19:49 UTC (Fri) by wahern (subscriber, #37304) [Link]
Like the reverse of vmsplice(2)? I think vmsplice() would suffice as-is. Even better, it only requires the sender to know about the interface; the receiver can keep using read().
Actually, an optimized sockets implementation could accomplish single copy if both sender and receiver are in the kernel. The kernel could just copy from one buffer directly to the next. But perhaps the code for such an optimization would be to odious.
Fast interprocess messaging Posted Jan 6, 2012 20:03 UTC (Fri) by wahern (subscriber, #37304) [Link]
Oops. I should've RTFA. They considered vmsplice() and thought it too much trouble to keep the processes' synchronized so messages don't end up buffered in the kernel. I don't see it. Either way signaling needs to occur between sender and receiver. I suppose all of this really cries out for a proper kernel AIO implementation (assuming there isn't one). Sender or receiver need a way to queue an op with an associated buffer.
|
|||||||||||||