<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: [geos-devel] An Immodest Proposal</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>This sounds like the most rational way forward on a gnarly problem.<BR>
+1<BR>
<BR>
Greg W.<BR>
Senior DBA<BR>
DigitalGlobe<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: geos-devel-bounces@lists.osgeo.org on behalf of Paul Ramsey<BR>
Sent: Mon 9/29/2008 1:42 PM<BR>
To: GEOS Development List<BR>
Subject: [geos-devel] An Immodest Proposal<BR>
<BR>
All,<BR>
<BR>
We are currently grappling with a pretty big issue in the PostGIS/GEOS<BR>
integration, namely that PgSQL allocates it's memory inside pools<BR>
(palloc/pfree), while GEOS allocates in general memory (malloc/free).<BR>
This (a) imposes a requirement of memory management perfection on<BR>
GEOS, otherwise the long-running postgres processes will leak and (b)<BR>
can lead to insoluble problems in certain implementation patterns.<BR>
<BR>
We have recently found one such problem pattern. When using<BR>
preparedgeometry in postgis, we create a GEOS geometry and associated<BR>
prepared geometry, these are duly malloc'ed, but we store references<BR>
to them in a palloc'ed struct in a memory pool which lasts for the<BR>
life of a postgres query. All is good (well, there are memory leaks<BR>
in the prepared stuff still, but those are theoretically fixable)<BR>
until the end of the query, when postgres cleans up the query memory<BR>
pool. All of a sudden the struct with the references to the geometry<BR>
and prepared geometry are gone -- but the objects have not been freed.<BR>
<BR>
Basically, the prepared geometry system will leak one geometry and one<BR>
prepared geometry for every SQL statement run, and there's SFA we can<BR>
do about it.<BR>
<BR>
My immodest proposal is to use geosInit as a location where users can<BR>
provide their own allocator/deallocators. Right now, geosInit lets us<BR>
set custom error handlers, so this extends the idea further.<BR>
<BR>
In GEOS we would override new/delete in GEOS to our own functions that<BR>
would check and see if the custom alloc/dealloc functions were set. If<BR>
not, they would fall back to malloc/free, otherwise use what was<BR>
provided. For postgis, we would provide palloc/pfree in our geosInit<BR>
calls.<BR>
<BR>
In this way, we could hook GEOS into the PgSQL pool system at runtime,<BR>
while still have it operate in the normal way when used with other<BR>
applications. And other applications with their own memory systems<BR>
could also more tightly integrate GEOS.<BR>
<BR>
Thoughts?<BR>
<BR>
P.<BR>
_______________________________________________<BR>
geos-devel mailing list<BR>
geos-devel@lists.osgeo.org<BR>
<A HREF="http://lists.osgeo.org/mailman/listinfo/geos-devel">http://lists.osgeo.org/mailman/listinfo/geos-devel</A><BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>