Opened 12 years ago

Closed 19 months ago

#540 closed enhancement (duplicate)

C-API: Allow passing custom memory managment functions

Reported by: strk Owned by: geos-devel@…
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 pramsey, 12 years ago

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 by strk, 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 strk, 12 years ago

Resolution: fixed
Status: newclosed

r3631 implements this by exposing GEOS_setAllocator and GEOS_setFreer functions.

comment:4 by strk, 12 years ago

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 by strk, 12 years ago

Milestone: 3.4.0GEOS Future
Priority: majorminor

Whole thing reverted with r3647

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

comment:6 by robe, 6 years ago

Milestone: GEOS FutureGEOS Fund Me

Milestone renamed

comment:7 by dbaston, 19 months ago

Resolution: duplicate
Status: reopenedclosed
Note: See TracTickets for help on using tickets.