> I guess i understand now: application allocates memory region from
> private address space and next shares it some way with other process.
> I also cannot recall anything with this functionality.  Well, on the
> other hand, what's the advantage of this scheme ?

It

(a) doesn't need a cooperative common ancestor (unlike the
    mmap(MAP_ANON|MAP_SHARED)+fork method)

(b) doesn't need a writeable file large enough to hold the memory
    (unlike the mmap-a-file method)

(c) has automatic teardown of the shared memory when the processes die
    (unlike the shmat() method)

(d) doens't involve a new, very constrained, and human-meaningless
    namespace (unlike the shmat() method)

(e) doesn't require that all memory that you might want to share be
    specially allocated ahead of time (unlike all other methods I'm
    aware of)

shm_open() helps somewhat with some of these, though I didn't see any
cross-reference to anything analogous to opendir()/readdir()/stat(),
which makes the namespace it uses rather problematic to deal with.

Item (e) is perhaps the most important to me as a coder.  There are
page-alignment issues (most architectures cannot share less than a
page, and thus one may end up actually sharing epsilon less than two
pages more than intended), but they don't matter for some applications.
(For example, if a process forks and keeps a socketpair between the
resulting processes, each end knows it can trust the other to be
non-malicious.)

/~\ 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