On Sat, 8 Feb 2014 08:26:43 -0500
Richard Hipp <[email protected]> wrote:
> > > The memory-mapped I/O is only enabled for windows, linux, mac
> > > OS-X, and solaris. We have found that it does not work on
> > > OpenBSD, for reasons we have not yet been able to uncove; but as
> > > a precaution, memory mapped I/O
> > is
> > > disabled by default on all of the *BSDs until we understand the
> > > problem.
> >
> > Was the problem ever identified?
> >
>
> OpenBSD lacks a coherent filesystem cache. That is to say, changes
> to a file made using write() are not necessarily reflected in mmap-ed
> memory right away. And change to a mmap-ed segment are not
> necessarily reflected in subsequent read() operations.
That's true, although it's not quite fair to say the filesystem cache
isn't "coherent". It's just not the Linux implementation.
It looks like a sprinkling of msync(2) would do the trick. My copy of
the Linux Programming Interface (chapter 49) says,
"However, a unified virtual memory system is not required by
SUSv3 and is not employed on all UNIX implementations. On such systems,
a call to msync() is required to make changes to the contents of a
mapping visible to other processes that read() the file, and the
MS_INVALIDATE flag is required to perform the converse action of making
writes to the file by another process visible in the mapped region."
That appears to be the situation you describe. It continues,
"Multiprocess applications that employ both mmap() and I/O
system calls to operate on the same file should be designed to make
appropriate use of msync() if they are to be portable to systems that
don?t have a unified virtual memory system."
I know portability is important to the SQLite project. Is this
particular issue a matter of manpower, know-how, or policy?
--jkl
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
