MAP_ANON, MAP_INHERIT and friends

54 views
Skip to first unread message

Yoav Cohen-Sivan

unread,
Feb 15, 1998, 3:00:00 AM2/15/98
to

In my ever-lasting attempt to fathom the rationale behind many Unix
syscalls, I have finally hit upon mmap(2). I am trying to understand why
all the major vendors, and POSIX, are passing up on the BSD extensions
to this call. The MAP_ANON convention seems much cleaner than the
/dev/zero trick, and if I understand correctly allows a nice way to get
rid of the last impediment to having mmap completely replace SysV shared
memory all together - sharing memory between unrelated processes. By
mmaping with a valid fd and MAP_ANON you can later pass the fd to
another unrelated process and have it mmap the same area.
Since I understand that the general consensus is that SysV IPC sucks,
this seems the correct choice: we could have a complete replacement for
SysV IPC: record-locking for semaphores, and mmap for shared memory.

So what's the deal? Simply programmer laziness on the part of all major
vendors?

Yoav

W. Richard Stevens

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

> The MAP_ANON convention seems much cleaner than the
> /dev/zero trick, and if I understand correctly allows a nice way to get
> rid of the last impediment to having mmap completely replace SysV shared
> memory all together - sharing memory between unrelated processes. By
> mmaping with a valid fd and MAP_ANON you can later pass the fd to
> another unrelated process and have it mmap the same area.

But if you specify MAP_ANON, 4.4BSD requires that the fd argument be -1.
There is no file associated with this, so it's only usable between related
processes.

> Since I understand that the general consensus is that SysV IPC sucks,
> this seems the correct choice: we could have a complete replacement for
> SysV IPC: record-locking for semaphores, and mmap for shared memory.

Actually, although System V messages and semaphores do have many warts,
System V shared memory is not that bad.

Rich Stevens

Yoav Cohen-Sivan

unread,
Feb 16, 1998, 3:00:00 AM2/16/98
to

W. Richard Stevens wrote:
>
> But if you specify MAP_ANON, 4.4BSD requires that the fd argument be -1.
> There is no file associated with this, so it's only usable between related
> processes.
>

In your own book (APUE) the last exercise of either chapter 12 or 14
asks how the fd argument to mmap can be used together with MAP_ANON to
share memory between unrelated processes. Was this changed from 4.3+BSD
to 4.4BSD?

Richard, you really owe it to us to write a second edition of APUE; you
can't write such a great book and then leave us all hanging out there
for 6 years...

>
> Actually, although System V messages and semaphores do have many warts,
> System V shared memory is not that bad.
>

SysV msgs, sems and shms all look and feel pretty much the same, so
what does shm do differently to make it "not that bad"?

> Rich Stevens

Yoav

W. Richard Stevens

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

> In your own book (APUE) the last exercise of either chapter 12 or 14
> asks how the fd argument to mmap can be used together with MAP_ANON to
> share memory between unrelated processes. Was this changed from 4.3+BSD
> to 4.4BSD?

I'm not sure what I was referring to there, but I just looked at the
BSD/OS source code, and cannot see an answer. Any solutions gladly
accepted.

> Richard, you really owe it to us to write a second edition of APUE; you
> can't write such a great book and then leave us all hanging out there
> for 6 years...

It's next on the queue. So many books, so little time ... If anyone has
specific topics they want to see covered (other than pthreads and the
realtime Posix stuff, obviously), please send me email.

> SysV msgs, sems and shms all look and feel pretty much the same, so
> what does shm do differently to make it "not that bad"?

All you do is call shmget() then shmat() and you're done. Just use
IPC_PRIVATE with the first (to avoid ftok()). With Posix shared memory
you have three steps: shm_open(), mmap(), and then either ftruncate()
or fstat(). IMHO Posix is "better" because shm_open() uses the existing
filesystem name space to identify the shared memory object (instead of
System V IPC keys) and uses the widespread mmap(), but again, the System V
method isn't that bad. Converting a program from System V shared memory
to Posix shared memory should be easy. Now System V message queues (with
their inability to notify when a message is placed onto an empty queue)
and System V semaphore sets are something else.

Rich Stevens

W. Richard Stevens

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

> > Actually, although System V messages and semaphores do have many warts,
> > System V shared memory is not that bad.
>
> Possibly all this will be covered in the Third Volume of "Unix Network
> Programming".

Volume 2 of the 2nd edition of UNP is "IPC: Interprocess Communication"
and I am nearing completion. It should be available late June.

Rich Stevens

Andrew Gierth

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

>>>>> "W" == W Richard Stevens <rste...@noao.edu> writes:

>> SysV msgs, sems and shms all look and feel pretty much the same, so
>> what does shm do differently to make it "not that bad"?

W> All you do is call shmget() then shmat() and you're done. Just
W> use IPC_PRIVATE with the first (to avoid ftok()). With Posix
W> shared memory you have three steps: shm_open(), mmap(), and then
W> either ftruncate() or fstat(). IMHO Posix is "better" because
W> shm_open() uses the existing filesystem name space to identify the
W> shared memory object (instead of System V IPC keys) and uses the
W> widespread mmap(), but again, the System V method isn't that bad.

I was often frustrated (when using SysV shared memory) by the
inability to resize a segment once created. (AIX has this as an
extension, but I've not seen it implemented anywhere else.) Another
weakness is the ludicrously low defaults that many systems (even from
major vendors) supply for the various administrative limits (especially
max. segment size).

--
Andrew.

comp.unix.programmer FAQ: see <URL: http://www.erlenstar.demon.co.uk/unix/>
or <URL: http://www.whitefang.com/unix/>

R!ch

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

On 17 Feb 1998, W. Richard Stevens wrote:

> > Richard, you really owe it to us to write a second edition of APUE; you
> > can't write such a great book and then leave us all hanging out there
> > for 6 years...
>
> It's next on the queue. So many books, so little time ... If anyone has
> specific topics they want to see covered (other than pthreads and the
> realtime Posix stuff, obviously), please send me email.

I'm in the (very) early stages of writing a more up to date UNIX
Systems programming book, although I intend to focus on Solaris 2.6.
I'm a big fan of Rich Stevens' books, and he sets the standard I
aspire to. Of course, Rich has an advantage over me - he's a full
time author. But he's got to finish UNP 2e V2 & 3 first! :-)

--
R!ch (Email is flakey at present: use rich...@keaton.uk.sun.com)

If it ain't analogue, it ain't music.
#include <disclaimer.h> \\|// - ?
(o o)
/==================================oOOo=(_)=oOOo========\
| Richard Teer richar...@uk.sun.com |
| |
| |
| WWW: www.rkdltd.demon.co.uk |
| .oooO |
| ( ) Oooo. |
\===================================\ (==( )==========/
\_) ) /
(_/


Roger Espel Llima

unread,
Feb 17, 1998, 3:00:00 AM2/17/98
to

In article <34E6E202...@netvision.net.il>,

Yoav Cohen-Sivan <y...@netvision.net.il> wrote:
>In my ever-lasting attempt to fathom the rationale behind many Unix
>syscalls, I have finally hit upon mmap(2). I am trying to understand why
>all the major vendors, and POSIX, are passing up on the BSD extensions
>to this call. The MAP_ANON convention seems much cleaner than the

>/dev/zero trick, and if I understand correctly allows a nice way to get
>rid of the last impediment to having mmap completely replace SysV shared
>memory all together - sharing memory between unrelated processes. By
>mmaping with a valid fd and MAP_ANON you can later pass the fd to
>another unrelated process and have it mmap the same area.

The BSD docs suggest this, but the kernel source very clearly disallows
MAP_ANON together with any fd other than -1. I looked at FreeBSD, but
I strongly suspect that it's inherited straight from 4.4BSD.

I, too, really wish this had been implemented, and had become standard.

Hell, if only the free BSD's and Linux supported it (none do), I'd use
it.

--
Roger Espel Llima
es...@llaic.univ-bpclermont.fr, es...@unix.bigots.org
http://www.eleves.ens.fr:8080/home/espel/index.html

Yoav Cohen-Sivan

unread,
Feb 19, 1998, 3:00:00 AM2/19/98
to

Roger Espel Llima wrote:
>
> The BSD docs suggest this, but the kernel source very clearly disallows
> MAP_ANON together with any fd other than -1. I looked at FreeBSD, but
> I strongly suspect that it's inherited straight from 4.4BSD.
>

I still don't get it: if it is documented, then the Berkeley CSRG must have
thought it was going in sooner or later. Why did they decide to drop it after
all? To my novice eyes it seems like a very useful addition, and one that
meshes nicely with its surroundings and Unix in general. So why did BSD drop
it, and why haven't any of the other vendors, or even Posix or The Open Group
picked it up?

> I, too, really wish this had been implemented, and had become standard.
>

OK, everyone thinks it is great, everyone wishes it to be included, and
yet... Nada!

> Hell, if only the free BSD's and Linux supported it (none do), I'd use
> it.
>
> --
> Roger Espel Llima
> es...@llaic.univ-bpclermont.fr, es...@unix.bigots.org
> http://www.eleves.ens.fr:8080/home/espel/index.html

Yoav

Roger Espel Llima

unread,
Feb 19, 1998, 3:00:00 AM2/19/98
to

In article <34EB60C5...@netvision.net.il>,

Yoav Cohen-Sivan <y...@netvision.net.il> wrote:
> I still don't get it: if it is documented, then the Berkeley CSRG must have
>thought it was going in sooner or later. Why did they decide to drop it after
>all?

It sounds to me like it was part of the plans, but wasn't ready at the
time they did the feature freeze, or something like that. It's
only documented in a paper somewhere in /usr/doc, not in a manpage...
You'd have to ask someone who was there at the time, to know for sure.

> OK, everyone thinks it is great, everyone wishes it to be included, and
>yet... Nada!

I'm not sure we count as "everyone" :)

Reply all
Reply to author
Forward
0 new messages