On 28 May 2013, at 05:56, Zaphod Beeblebrox <zbee...@gmail.com> wrote:
> Urm... Isn't the use of shared memory the more obvious way to transfer data > between processes? Am I missing some nuance? I can't speak for Luigi's use-case, but the Binder APIs in BeOS and Android call for this kind of copy. The receiving process contains a ring buffer and the messages are pushed into it. You could implement this in shared memory, but only if you trusted the sender not to modify the data at incorrect times or write invalid values into the metadata (or, in the case of Binder, to forge the pid / uid of the sender, which it attached to each message). The kernel must act as an intermediary to enforce correct use of the buffer and also to allow the caller to block until space is available (perhaps by scheduling the receiver to run for a bit) without spinning and to allow multiple writers to be queued when there is no space, rather than have them racing. The buffers are in the receiver's memory space because it is designed for resource constrained environments and for malicious parties to communicate, so it avoids a potential DoS by filling up kmem with buffers - a process that c reate a load of receive ports will simply fill up its own address space and die. In the specific case of binder, you can avoid the overhead of extra VM lookups by mapping the buffer into the address space of every sender when you open the connection, but marking its access as privileged mode only. This means that you'll be doing a simple copy. You can also align the receive buffer in such a way that the consume counter is on a different page to the rest of the data structure, allowing you to get a page fault when the buffer transitions from full to non-full and there are messages waiting. David _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
