Re: ancient OS history, ARM is sort of channeling the IBM 360

scott@slp53.sl.home (Scott Lurndal) writes:

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

John Levine <johnl@taugh.com> writes:

As I think I said before, these days you map the file into your
address space and read or write it like a long string, so its all
locate all the time.

>
Reading with mmap() appears to be quite common, either directly or
through libaries like glibc which use mmap() for buffered input where
possible.  For writing, using mmap() poses some difficulties:
>
* Writing to an mmap()ed region has weaker atomicity semantics than
 write().

>
That depends - if all writers are using mmap, atomicity is provided
by other mechanisms (process-scope mutex, sysv or posix semaphores,
etc).
>
An application where one writes via mmap and others read
using stdio or read/write/pread/pwrite simulataneously
is poorly designed.

"An application"?  I live in a world where all kinds of programs can
access the same files.  How such a program works internally is often
not known to the designers of the others.

In practice your advice boils down to avoiding to write with mmap().

>

>
* mmap() works on pages (not in the interface, fortunately, but
 internally), but for writing you want byte granularity.  The
 difference is not a big problem for reading, but it is a bigger one
 for writing.

>
In my experience, mmap is most often used when record-granularity
is required, rather than treating the mapped region as a
stream-of-bytes.

I usually mmap() the whole file.

* You have to extend the file length with a separate system call, and
 then mmap() the new area, so you might just as well use write().

>
False economy.   ftruncate is a single system call.

Yes, that's the one that extends the file length.  ftruncate()
followed by mmap() are two system calls.  And at some point you also
want to msync() (although not for each ftruncate).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>