C-API: Allow passing custom memory managment functions

[strk]

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)

[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.

[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 ?

[strk]

r3631 implements this by exposing GEOS_setAllocator and GEOS_setFreer functions.

[strk]

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.

[strk]

Whole thing reverted with r3647

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