>> Our system is a lot more complex than just 1 image source and 1
>> image sink.  We have several other processes that may also require
>> images.
> You can share memory with several processes.  E.g. one writes and 10
> other processes are reading it.

Yes indeed, and it can greatly improve performance.  (I've often wished
for a way to send mappings for memory through AF_LOCAL sockets, so that
unrelated processes can rendezvous with an AF_LOCAL socket and share
memory without needing to have a file around to be mmap()ped.
Alternatively, a way to get a file descriptor on a memory area; that
descriptor could then be passed by existing mechanisms and mmap()ped to
produce the sharing.)

I once wanted to build something like dd but that overlapped reads and
writes.  I ended up making it mmap MAP_ANON memory before forking into
a reader process and a writer process; they transferred ownership of
large blocks of memory by sending tiny tokens through a pipe.  It
greatly improved speed when doing large copies from one raw disk to
another, even if they're on the same SCSI bus.

If your processes have a common ancestor that can map memory for them,
you could do likewise.  If not, you may have to create a file for them
to mmap(), ugly as it may be.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B