On Wed, 26 Jun 2002, Tom Lane wrote:
> Curt Sampson <cjs@cynic.net> 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
thisworks, 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
thenanother might read() it afterwards but not see the changes. Postgres should not try to deal with hypothetical
systemsthat 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
twoare 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'dmemory. And there would be no point in making it otherwise. Mmap is designed to let you share memory; why
makea 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 <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
