Re: Re: [PATCHES] A patch for xlog.c

ncm(at)zembu(dot)com (Nathan Myers) writes:
> This is supported on Linux and BSD, but not on Solarix 7. It's not
> necessary; you can just map /dev/zero on SysV systems that don't
> have MAP_ANON.

HPUX says:

The mmap() function is supported for regular files. Support for any
other type of file is unspecified.

> But I don't know of any reason to avoid mapping an actual inode,

How about wasted I/O due to the kernel thinking it needs to reflect
writes to the memory region back out to the underlying file?

> Since mmap() is how everybody implements shared libraries,

Now *there's* a sweeping generalization. Documentation of this
claim, please?

> The mmap architecture comes to us from the Mach microkernel memory
> manager, backported into BSD and then copied widely.

If everyone copied the Mach implementation, why is it they don't even
agree on the spellings of the user-visible flags?

This looks a lot like exchanging the devil we know (SysV shmem) for a
devil we don't know. Do I need to remind you about, for example, the
mmap bugs in early Linux releases? (I still vividly remember having to
abandon mmap on a project a few years back that needed to be portable
to Linux. Perhaps that colors my opinions here.) I don't think the
problems with shmem are sufficiently large to justify venturing into
a whole new terra incognita of portability issues and kernel bugs.

regards, tom lane