c++memorypostgisfunction-pointers

Custom memory handling in postGIS


I am currently working on a c++ project leveraging the features of Postgis. Postgis provides handles to use custom memory allocators for the memory management. The allocator should be of the signature:

typedef void* (*lwallocator)(size_t size);

I have a memory allocator, that is of the signature:

typedef void* (*lwallocator)(SomeInfo info, size_t size);

Any guidance would be helpful on how to pass my custom allocator to postgis(lwgeom_set_handlers).

Thanks in advance!

I tried having global variable. But, SomeInfo in the above signature is known dynamically, and there will be multiple instances at the same time,hence, I will not be able to have a global variable.


Solution

  • You would need to use a global because lwgeom_set_handlers belongs to the global context, i.e. it is not part of an object that can have it's own separate state.

    Consider this workflow:

    A:

    1. we decide to use pool_1 to allocate memory; this is SomeInfo pool_1

    2. call lwgeom_set_handlers to use allocator pointing to pool_1

    3. lwgeom now does a bunch of stuff and want to allocate 12 objects, it will call the allocator set above and 12 objects get allocated form pool_1

    B:

    1. now we want to use pool_2

    2. call lwgeom_set_handlers to use allocator pointing to pool_2

    3. lwgeom need to allocate 4 objects and does that with above allocator from pool_2

    Implementation:

    A:

    1. assign active_pool = &pool_1;

    2. do stuff with lwgeom library that requires allocation

    B:

    1. create pool_2 in case it was not created above

    2. assign active_pool = &pool_2;

    3. do stuff with lwgeom library that requires allocation

    EDIT: MSalters makes a good point below, I have not addressed the deallocation and it is not a simple active_pool->freeMemory(mem_ptr), because you need to address the proper pool.

    I see 2 options here:

    1. The deallocator (and reallocator) passed to lwgeom_set_handlers, would need to have access to the complete list of pools. It will go through all of the pools, and would need a method that checks whether the memory that needs to be freed belongs to this pool. If it does, then calls freeMemory on the pool, and breaks the search.

    2. The second option, in my mind is tied to a Design decision: you wanted to use memory pools because at some point in time you plan to deallocate the complete range of addresses belonging to a pool, a freeAll if you will, for optimization purposes. In such a case your deallocator does nothing, because the module using postGIS, will decide to deallocate at the proper time (probably after releasing any objects created by the lib). NOTE: Your reallocator would need to have the implementation described at point 1