[geos-devel] [GEOS] #208: Provide alternate malloc/free at run time

GEOS geos-trac at osgeo.org
Tue Sep 30 00:01:56 EDT 2008


#208: Provide alternate malloc/free at run time
-------------------------+--------------------------------------------------
 Reporter:  pramsey      |       Owner:  geos-devel at lists.osgeo.org
     Type:  enhancement  |      Status:  new                       
 Priority:  major        |   Milestone:  3.1                       
Component:  Default      |     Version:  svn-trunk                 
 Severity:  Unassigned   |    Keywords:                            
-------------------------+--------------------------------------------------
 We are currently grappling with a pretty big issue in the PostGIS/GEOS
 integration, namely that PgSQL allocates it's memory inside pools
 (palloc/pfree), while GEOS allocates in general memory (malloc/free).
 This (a) imposes a requirement of memory management perfection on
 GEOS, otherwise the long-running postgres processes will leak and (b)
 can lead to insoluble problems in certain implementation patterns.

 We have recently found one such problem pattern. When using
 preparedgeometry in postgis, we create a GEOS geometry and associated
 prepared geometry, these are duly malloc'ed, but we store references
 to them in a palloc'ed struct in a memory pool which lasts for the
 life of a postgres query.  All is good (well, there are memory leaks
 in the prepared stuff still, but those are theoretically fixable)
 until the end of the query, when postgres cleans up the query memory
 pool. All of a sudden the struct with the references to the geometry
 and prepared geometry are gone -- but the objects have not been freed.

 Basically, the prepared geometry system will leak one geometry and one
 prepared geometry for every SQL statement run, and there's SFA we can
 do about it.

 My immodest proposal is to use geosInit as a location where users can
 provide their own allocator/deallocators.  Right now, geosInit lets us
 set custom error handlers, so this extends the idea further.

 In GEOS we would override new/delete in GEOS to our own functions that
 would check and see if the custom alloc/dealloc functions were set. If
 not, they would fall back to malloc/free, otherwise use what was
 provided.  For postgis, we would provide palloc/pfree in our geosInit
 calls.

 In this way, we could hook GEOS into the PgSQL pool system at runtime,
 while still have it operate in the normal way when used with other
 applications. And other applications with their own memory systems
 could also more tightly integrate GEOS.

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/208>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).


More information about the geos-devel mailing list