🚀 go-pugleaf

From:  mikes@oakhill.sps.mot.com (Mike Schultz)

In article <700@longway.TIC.COM> From:  karish@mindcrf.uucp
>In article <696@longway.TIC.COM> [Doug Gwyn] writes:
>>Like calling mmap() instead of whatever the POSIX routine is.
>
>I hope we don't have to name a new interface every time a new standard
>restricts or changes the syntax of an old one.  Especially when the
>old interface is difficult to use portably anyway.

I can't tell if you are for or against the use of the new interface,
especially with the comment about the "difficult to use portably anyway"
comment.

The reason that the new interface was choosen is this:

For REAL TIME purposes, shared memory functionality  is very useful, but
REQUIRING it to map files would be unacceptable for many implementations.  Even
the suggestion that the file would be on a RAM disk is not acceptable.  The
application should be able to request the shared memory to be mapped in
and that is the LAST thing that the operating system should HAVE to do with
it.

Thus P1003.4 needed an interface that did not require that files be mapped.
Mmap was existing practice, but it would have to be gutted in order to
used it.  It was felt that there was two courses to take here, both of which
was certain to draw ballot objections.

The solution choosen was one that was a subset of mmap's functionality, but
was not the same interface.  This had two advantages:  First, it could be
implemented with mmap using macros.  Second, if an implementation wished
to contain a pure shared memory interface, without routing it thru the
blasted file system, it could do that as well as implementing mmap.

Anyway, that was the reasoning then.

Now here are the latest developments.  SVR4 has taken the step of implementing
mmap without requiring it to be a file.  It states that one is mapping in
a virtual memory object instead.  It may be possible for the SVR4 wording of
mmap to be used as existing practice.  There will have to be some functionality
labeled as implementation defined.

We'll see how it goes.

Mike Schultz
mikes@oakhill.mot.sps.com

And soon to be 

ms@RMC.Liant.com

Volume-Number: Volume 20, Number 16