To eliminate this disadvantage I present the model of an extended mmap() call, that allows for mapping arbitrary stream objects into a program's address space. A program using this extended call can be written adhering to only one paradigm of interacting with external objects, the one of mmap(), and still avoid unecessary copying.
The properties of the memory object that is created by mapping a stream object, are modeled after the behavior of a mapped file, though they still keep some properties of the original object, e.g. the size of a pipe or a socket is by definition not known. Although mmap() cannot change this, the large virtual address spaces of current architectures make the model very useful.
Using the example of memory mapped pipes I specify the model of extended mmap() in detail and implemented it in Linux.
Extended memory mapping, especially the shift from page granularity
to byte granularity, requires some refinements in virtual memory management.
As expected, the versions using mmap() of ordinary files performed better. The difference being mostly in system time used. For the standard IO implementations the measurements required more than twice as much time for mmap().
A second experiment measured the run-times of programs communicating via a pipe. Access methods were either read()/write() or mmap(). Here we see that the result was not as expected. The slight increase of by factor of 1.1 for mmap() can be attributed to the sample implementation not being optimized.
The whole table of measurements can be found on this site.
To read all about extended-mmap() take a look to my thesis
Use one of the modified programs (wc, grep) or one of the test-programms (cat, pipemap) to learn more about memory mapping of pipes.