Re: [Boost-bugs] [Boost C++ Libraries] #1975: windows_shared_memory implicitly commits virtual memory

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #1975: windows_shared_memory implicitly commits virtual memory
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2008-05-30 17:40:14

#1975: windows_shared_memory implicitly commits virtual memory
----------------------------------------------------+-----------------------
  Reporter:  Jason Sachs <jsachs_at_[hidden]>  |       Owner:  igaztanaga  
      Type:  Bugs                                   |      Status:  reopened    
 Milestone:  Boost 1.36.0                           |   Component:  interprocess
   Version:  Boost 1.35.0                           |    Severity:  Problem     
Resolution:                                         |    Keywords:              
----------------------------------------------------+-----------------------
Changes (by Jason Sachs <jsachs_at_[hidden]>):

  * status:  closed => reopened
  * resolution:  invalid =>

Comment:

 Replying to [comment:1 igaztanaga]:
 > I don't consider this a bug, but a feature. Managing pages on-demand is
 not a feature currently provided by Interprocess and I find difficult this
 to be managed by Interprocess.
 >
 > As mentioned, an alternative would be to use several managed segments
 created on demand by the user.

 I hope you won't take offense if I reopen this. I do agree that managing
 arbitrary pages on demand is something unreasonable. However, the problem
 I'm facing, and the only thing I'm looking for a resolution, is the
 implications of (a) having to specify a fixed maximum size for the
 segment, despite possible/probable usage that is much smaller and (b) the
 Boost library's only option is to commit all that virtual memory at once
 in Windows.

 I've looked around a little bit at the source files for
 boost::interprocess and it looks like there some facilities in
 http://svn.boost.org/svn/boost/trunk/boost/interprocess/detail/managed_memory_impl.hpp

 to grow() file sizes. The memory reserved by
 CreateFileMapping/MapViewOfFile can't grow, but what if there were a
 separate "size" and "max_size" in
 http://svn.boost.org/svn/boost/trunk/boost/interprocess/mapped_region.hpp

 ? (which appears to be the class that calls MapViewOfFile via
 map_view_of_file_ex()) "max_size" would represent the argument passed to
 CreateFileMapping (with the SEC_RESERVE flag) / MapViewOfFile, and "size"
 representing the portion of that memory allocated; calls to grow() would
 call VirtualAlloc, not in a haphazard random-access per-page way, but
 merely to increase the size used by the shared memory segment, in a
 sequential, linear (or exponential if that makes sense) fashion.

-- 
Ticket URL: <http://svn.boost.org/trac/boost/ticket/1975#comment:3>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.