Opened 12 years ago
Closed 22 months ago
#540 closed enhancement (duplicate)
C-API: Allow passing custom memory managment functions
Reported by: | strk | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | GEOS Fund Me |
Component: | Default | Version: | main |
Severity: | Unassigned | Keywords: | |
Cc: |
Description
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 http://trac.osgeo.org/postgis/ticket/1802)
Change History (7)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
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 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
r3631 implements this by exposing GEOS_setAllocator and GEOS_setFreer functions.
comment:4 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 by , 12 years ago
Milestone: | 3.4.0 → GEOS Future |
---|---|
Priority: | major → minor |
comment:7 by , 22 months ago
Resolution: | → duplicate |
---|---|
Status: | reopened → closed |
Superseded by https://github.com/libgeos/geos/issues/704
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.