id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
1975,windows_shared_memory implicitly commits virtual memory,Jason Sachs <jsachs@…>,Ion Gaztañaga,"http://svn.boost.org/svn/boost/trunk/boost/interprocess/windows_shared_memory.hpp
windows_shared_memory::priv_open_or_create() is the function that calls CreateFileMapping() to reserve a segment of virtual memory. It does not specify either SEC_RESERVE or SEC_COMMIT, and the docs for CreateFileMapping() say that SEC_COMMIT is assumed. 

Either this is a small bug and SEC_COMMIT should be specified explicitly (w/ no change in behavior or other code needed), or there is a larger problem and SEC_RESERVE should be used instead.

The problem with SEC_COMMIT is as follows.
Suppose you have a N processes where each process i=0,1,...N-1 is going to need a pool of related memory with a maximum usage of sz[i] bytes, where sz[i] is not known beforehand but is guaranteed less than some maximum M, and has a mean expected value of m where m is much smaller than M. From a programmer's standpoint, the best way to handle this would be to reserve a single shared memory segment and ask Boost::interprocess to make the segment size equal to M.

But if I use the existing boost libs to do this, then because SEC_COMMIT is used, my total system resource usage for virtual memory is N*M (instead of sum(sz[i]) which is likely to be much smaller).

SEC_RESERVE should be used instead. This is more complicated because then you need to do VirtualAlloc or something later to actually commit the memory on-demand (in fact I'm not quite sure how this would have to work esp. since I'm unfamiliar w/ the inner workings of Boost::interprocess).

as an aside, it would be helpful for me to find out sooner rather than later whether this is considered a valid bug that can be addressed in the coming months; otherwise I would have to change my architecture + use multiple shared memory segments in order to make more efficient use of the limited total system resource of virtual memory.",Bugs,closed,Boost 1.36.0,interprocess,Boost 1.35.0,Problem,wontfix,,