Steven> The user cannot reliably release the memory allocated by monotonic, if monotonic is used simultaneously in multiple independent locations in a program.
This is true, and why I added regions.
This means that only an application programmer can decide when it is safe to clean up and libraries cannot safely use monotonic::allocator without running the risk of allowing memory usage to balloon out of control.
However, if you pass a container that uses a monotonic allocator to a library, you should know what that library will do with it. I also added chain<> to help with the most obvious problem of vector resizing, however this doesnt help in the general case. But even so, the user can control and limit the amount of memory used by using a region with a fixed-size storage. In general, I agree that there is a wide scope for misuse. There is a good case for adding an introspection system to debug builds that self-monitors and warns the user about probable problems. It can be argued that any system that needs this is too risky to use.
Further, I shudder to imagine the difficulty of making sure that this constraint is not violated in a large program.
Again, regions and local<> provide what is needed to manage this. Anyway, if you want to release memory in this way, you
should be using something like monotonic::local_storage, to which Boost.Pool has no equivalent.
See above. I'm rapidly concluding that using global storage with
monotonic is much too fragile and dangerous.
I agree that there are risks. Perhaps it can be renormalised so that the default allocator has to be supplied with a region and uses thread-safety by default? allocator<int, Region> default; // region is required, uses shared_storage allocator<int, Region, monotonic::global_tag> alloc; // uses single global storage allocator<int, Region, monotonic::local_tag> alloc; // uses thread local storage Would this alleviate some of your concerns?
In Christ, Steven Watanabe
Regards, Christian