[ On Wednesday, July 9, 2003 at 09:07:03 (+0100), Christoph Hellwig wrote: ]
> Subject: Re: fsync performance hit on 1.6.1
>
> On Wed, Jul 09, 2003 at 03:01:30AM -0400, Greg A. Woods wrote:
> > a shared memory "object".  To quote the rationale from P1003.1-2001:
> > 
> >      On implementations where memory objects are implemented using the
> >      existing file system, the shm_open() function may be implemented
> >      using a macro that invokes open(), and the shm_unlink() function
> >      may be implemented using a macro that invokes unlink().
> > 
> > There had to have been some pretty strange politics going on to have
> > forced the creation of the POSIX shared memory objects API even when the
> > old POSIX mmap() was already a well known option!
> 
> Umm, posix SHM _does_ use mmap.  It just uses shm_open to get a suitable
> fd, on Solaris and Linus that would be on tmpfs.

Yes, that's my point.  :-)

If you know how IEEE standards committees work and you understand how
much they (are supposed to) hate inventing new things, the fact that
they invented shm_open and shm_unlink() suggests that some strong
member(s) of the comittee were just completely and totally unwilling to
allow for mmap() to work on all normal files and that the only way they
would be happy with mmap() becoming the true standard shared memory
interface was if it was required that the file descriptors it used be
allocated by some special new function.

You would think shared memory would be simpler to describe and discuss
than something like message queues which have lots of fancy features,
since it is, after all, just a chunk of memory storage that can be
mapped into the address space of multiple processes.  However because of
this strange use of mmap() and all the qualifiers they put on it for
POSIX, folks like Bill Gallmeister in his O'Reilly "POSIX.4" book
actually spend more pages describing shared memory and give all kinds of
caveats about its use.  The SysV SHM API is trivial by comparison to POSIX.

I don't know why POSIX doesn't include MAP_ANON either -- that would
have made things ever so much simpler!  The rationale in P1003.1-2001
claims they decided to use the SysVr4 mmap() implementation as the basis
of the POSIX API, and indeed SysVr4 lacks MAP_ANON, however MAP_ANON was
very well known before mmap() was finalized since 4.3net2 was already
widely disseminated  (1003.4 was still in draft at the end of 1991).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>