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 =>


 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
 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
 ? (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: <>
Boost C++ Libraries <>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:49:57 UTC