Opened 6 years ago

Last modified 6 years ago

#540 reopened enhancement

C-API: Allow passing custom memory managment functions

Reported by: strk Owned by: geos-devel@…
Priority: minor Milestone: GEOS Future
Component: Default Version: master
Severity: Unassigned Keywords:


We could take custom allocator and deallocator functions for use while using the C-API. Doing so PostGIS (for example) could use the memory poolers provided by PostgreSQL catching any leak at statement end and also allowing for query interruption (see

Change History (5)

comment:1 Changed 6 years ago by pramsey

I did this once upon a time because I thought it was the only way to stop leakage in the prepared geometry code. It mostly worked (though I was plenty worried about it) with the exception of the global geometryfactory declared in the capi which persistently got instantiated in system memory, not in the postgres pools.

comment:2 Changed 6 years ago by strk

I wouldn't be too much concerned about system vs. postgresql, things shouldn't get worst than they are in that respect. What concerns me more is speed. My early tests show that allocation functions are called _a_lot_ for very small amount of bytes (often 4!). Didn't test the actual effects of using palloc and friends about that.

Oh, another thing is that alloc/dealloc callbacks can't be per-thread, but we can't do much about it.

Hey, aren't the above limitation minor for the plus of possibly interrupting an ST_Buffer ?

comment:3 Changed 6 years ago by strk

Resolution: fixed
Status: newclosed

r3631 implements this by exposing GEOS_setAllocator and GEOS_setFreer functions.

comment:4 Changed 6 years ago by strk

Resolution: fixed
Status: closedreopened

The implementation isn't good in that installs _global_ operator new/delete. Doing so affects not only GEOS but any other C++ library linked into the final application (and the application itself).

I think I'm going to revert the whole CustomAllocator? class and C-API interface for it.

comment:5 Changed 6 years ago by strk

Milestone: 3.4.0GEOS Future
Priority: majorminor

Whole thing reverted with r3647

Priority reduces with the advent of explicit interruptability (see from r3642 on)

Note: See TracTickets for help on using tickets.