boost pool_allocator memory pool behavior clarification

Question

The boost documentation as below:

Note

The underlying singleton_pool used by the this allocator constructs a pool instance that is never freed. This means that memory allocated by the allocator can be still used after main() has completed, but may mean that some memory checking programs will complain about leaks.

I am confused since I checked the code and the singleton_pool still seem to be created only on the heap of the current process. I.e. if the process is killed by the OS, such pool will be released anyway? Then the above notes merely means if some daemon thread keeps on and such pool is still available after main()? Or it actually means the pool won't be released even after the entire process is killed?

It also seems to me both pool_allocator and fast_pool_allocator are using the identical mechanism to allocate memory i.e. from such a singleton_pool singleton. However this note isn't specified for the fast_pool_allocator. I would reckon both of them behaves the same for such a note above. Am I correct?

Please help. Thanks.

"after main has completed" but before the program has exited... There are still a few things to do after main. But of course the memory is returned to the OS when the program dies (assuming your OS handles it, not some limited embedded platform). — Marc Glisse, Oct 16 '15 at 07:36
@MarcGlisse That's it?? I thought there is some black magic I didn't grasp on code ... D'or. — Alex Suo, Oct 16 '15 at 07:38
@MarcGlisse Mind if write that as the answer so I could accept thanks :) — Alex Suo, Oct 16 '15 at 08:05
@MarcGlisse As Alex suggests that should be an answer not a comment. It would be worth noting that thing that happen after `main()` that the note might be relevant to include anything registered to `std::atexit()` and the destructor of file scope variables (i.e. global variables). — Persixty, Oct 16 '15 at 08:25

score 1 · Accepted Answer · answered Jan 27 '17 at 04:32

singleton_pool implements thread-safe(under some conditions) singleton without locks, using the feature of initialization of non-local static variables. The part of source code:

template <typename Tag,
    unsigned RequestedSize,
    typename UserAllocator,
    typename Mutex,
    unsigned NextSize,
    unsigned MaxSize >
class singleton_pool
{
   ...
   struct object_creator
   {
      object_creator()
      {  // This constructor does nothing more than ensure that instance()
         //  is called before main() begins, thus creating the static
         //  T object before multithreading race issues can come up.
         singleton_pool<Tag, RequestedSize, UserAllocator, Mutex, NextSize, MaxSize>::get_pool();
      }
      inline void do_nothing() const
      {
      }
   };
   static object_creator create_object;
}; // struct singleton_pool

non-local variables are initialized as part of program startup, before the execution of the main function begins and get torn down when the program terminates. So that singleton_pool will be created before the main(), and destroyed after main(). If the process is terminated anyway, of course pool will be released.

boost pool_allocator memory pool behavior clarification

1 Answers1