[geos-devel] An Immodest Proposal

[Stephen Woodbridge]

Paul,

I think this is an outstanding proposal. While I don't know all the ins 
and outs of this issue, this method is sound and is similar to what 
SQLite uses to allow developers to use the default memory functions or 
to override them with their own.

Does this approach have any down side to it?
Are there cases where this might be bad? like someone has a pointer to 
the palloc'd struct in the memory pool that was just freed.

I assume potential cases were thought through, so in lieu someone 
pointing out such a case, I would offer a +1 (as a vote of confidence 
for a good idea, since I don't have a vote that counts here.)

-Steve

Paul Ramsey wrote:
> All,
> 
> 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.
> 
> Thoughts?
> 
> P.
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel