Subject: Re: [Boost-bugs] [Boost C++ Libraries] #9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one provided in file_mapping
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-08-21 09:35:42
#9019: Bug: mapped_region shouldn't create a new file mapping but reuse the one
provided in file_mapping
-------------------------+-------------------------------------------------
Reporter: | Owner: igaztanaga
michal.fronczyk@⦠| Status: new
Type: Bugs | Component: interprocess
Milestone: To Be | Severity: Optimization
Determined | Keywords: interprocess mapped_region
Version: Boost | file_mapping
1.54.0 |
Resolution: |
-------------------------+-------------------------------------------------
Comment (by igaztanaga):
I think all file mappings share the same cached pages as coherency must be
maintained:
http://msdn.microsoft.com/en-
us/library/windows/desktop/aa366763(v=vs.85).aspx
"With one important exception, file views derived from any file mapping
object that is backed by the same file are coherent or identical at a
specific time. Coherency is guaranteed for views within a process and for
views that are mapped by different processes."
(The exception is network files)
I don't think the issue is related to destroying the file mapping (in fact
the file mapping is destroyed just after mapping the memory with
MapViewOfFile), but because the mapped_region is unmapped
(UnmapViewOfFile). The OS knows that no other thread is mapping those
pages so it could think it's a good opportunity to release them (although
if there is enough file cache, it should be still there). I'm not sure how
this can be fixed as it's quite OS dependent.
Mapping the whole file shouldn't be a problem, at least in windows, as
physical memory committed when the page is read (although I guess Windows
will prefetch some pages).
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/9019#comment:4> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:13 UTC