Mmap means many things to many people.

Using mmap is most often not a matter of
performance as much as it is a matter of
flexibility: being able to mmap files is about
as close as most operating systems get to
exposing the underlying page table hardware,
which lets applications that aren't happy with
the OS-provided interface essentially design
their own. The canonical example is databases,
which would really prefer to be operating systems
except for the whole having to write hardware
drivers thing. 9vx is another example.

i've noticed that some combinations of words
are scarier than others.

☺

- erik

* Russ Cox swtch.com> wrote:

Hi,



I don't know much of native plan9 (only using plan9port), but IMHO
an full mmap() is a really nice thing. It can make a lot things
easier if you just map the whole file into the process' memory and
let the kernel handle the actual IO.

Some time ago I hacked up a little XML-based database (just to
show myself that it needn't to be that ugly slow as Xindice ;-)),
and being able to conveniently work with pointers instead of ugly
seek() made really fun ;-P

cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service

the word "superficially" should be in there somewhere.

On Tue, 29 Jul 2008 12:52:14 +0400, Enrico Weigelt
wrote:

Hi!

Yes, it is comfortable. But just think a bit - what will you do in the
mmap implementation when you had mapped a remote file (in Plan9 you can't
be sure some file is local or it is really just a file), and the
connection has just been broken? Surprise!

For example, in Windows you will have an "access violation". It is very
funny to rewrite a code for using the good old file i/o instead of mmap.
In Linux you can't map a non-regular file.

Yes, you can read entire the file into the memory, but a size of the file
can be very big and you will destroy the main advantage of mmap - the
reading of only needed pieces of the file, not entire.

I beleive, mmap is not for distributed systems.

where's jim when you need him?

you can't make the assumption that a file is local in *ix, either.

- erik

On Tue, Jul 29, 2008 at 8:19 AM, erik quanstrom coraid.com> wrote:

in fact, for the last 20 years, every program run on a sunos/solaris
machine has used mmap for the exec.

ron

On Tue, Jul 29, 2008 at 8:04 AM, Alexander Sychev gmail.com>wrote:

ron minnich wrote:

mmap() is everywhere on Solaris. Even when you do something as trivial
as sort(1) --
it'll try to mmap() the operands and only if that fails it is going to
use read()/write().

Thanks,
Roman.

P.S. Which is not that bad of an optimization if you ask me...

As far as interfaces go, mmap() is pretty tragic - the underlying
translation structures can express more interesting things, some of
which are even worth doing.

There have even been OSes that let userland apps play with their address
spaces in far more interesting ways - KeyKOS and EROS come to mind. And
they were even fast, or something.

In a system like Plan 9, where your file servers are on the other side
of a 9P link, this mmap thing seems dubious. If what you want is the
convenience that you get from having all the bytes in memory, reading
them all in wouldn't be too hard. mmap()s magic really arises when you
have a page-cache-like-thing.

--vs