On Wed, 26 Jun 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > Note that your proposal of using mmap to replace sysv shared memory
> > relies on the behaviour I've described too.
>
> True, but I was not envisioning mapping an actual file --- at least
> on HPUX, the only way to generate an arbitrary-sized shared memory
> region is to use MAP_ANONYMOUS and not have the mmap'd area connected
> to any file at all. It's not farfetched to think that this aspect
> of mmap might work differently from mapping pieces of actual files.
I find it somewhat farfetched, for a couple of reasons:
1. Memory mapped with the MAP_SHARED flag is shared memory,
anonymous or not. POSIX is pretty explicit about how this works,
and the "standard" for mmap that predates POSIX is the same.
Anonymous memory does not behave differently.
You could just as well say that some systems might exist such
that one process can write() a block to a file, and then another
might read() it afterwards but not see the changes. Postgres
should not try to deal with hypothetical systems that are so
completely broken.
2. Mmap is implemented as part of a unified buffer cache system
on all of today's operating systems that I know of. The memory
is backed by swap space when anonymous, and by a specified file
when not anonymous; but the way these two are handled is
*exactly* the same internally.
Even on older systems without unified buffer cache, the behaviour
is the same between anonymous and file-backed mmap'd memory.
And there would be no point in making it otherwise. Mmap is
designed to let you share memory; why make a broken implementation
under certain circumstances?
> In practice of course we'd have to restrict use of any such
> implementation to platforms where mmap behaves reasonably ... according
> to our definition of "reasonably".
Of course. As we do already with regular I/O.
cjs
--
Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
