Subject: [Boost-bugs] [Boost C++ Libraries] #7794: Not needed code for mapped files in windows
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-12-13 23:40:21
#7794: Not needed code for mapped files in windows
----------------------------------+-----------------------------------------
Reporter: lodos@⦠| Owner: igaztanaga
Type: Tasks | Status: new
Milestone: To Be Determined | Component: interprocess
Version: Boost 1.52.0 | Severity: Optimization
Keywords: mapped file grow |
----------------------------------+-----------------------------------------
The exchange below took place on the boost developer list, it describes
the request. Thank you.
> > > When you grow a managed mapped file, the current
> > > implementation fills all the new space with zeroes. This is less
> > > efficient than just resizing the file. The comments in the code
> > > implies there is a reason, so what is it?
> >
> > Interprocess tries to simulate as much as possible POSIX guarantees.
> > truncate() POSIX system call guarantees that "If the file is
> extended,
> > the extended area appears as if it were zero-filled". In windows,
> > SetFileValidData/SetEndOfFile does not zero-fill the extended size so
> > Interprocess needs to write it.
> Given that the mapped file content is not part of the library
> interface, and the only expected user of the mapped file is the library
> itself, why waste time in Windows? Seems to me that a requirement that
> files should be identical is too strong, as long as they work and
> perhaps don't affect platform portability. File portability between
> platforms should be warranted? What about platforms with different
> endianness?
I need to investigate it, but I tried to support similar behaviour for
internal file-handling functions. I'll need to think it again. Please fill
a ticket so this doesn't get lost when reviewing pending issues.
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/7794> 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:11 UTC