[geos-devel] An Immodest Proposal

[Paul Ramsey]

Well, there's a day and a half of my life down the drain... :/

P

On Wed, Oct 1, 2008 at 3:12 PM, Mark Cave-Ayland
<mark.cave-ayland at ilande.co.uk> wrote:
>
> On Wed, 2008-10-01 at 11:33 -0700, Paul Ramsey wrote:
>> Mark, there's two issues at play here:
>>
>> (1) - GEOS leaks, independently of the pgsql use of it, and yes, that
>> should be fixed
>> (2) - when you place a reference to a GEOS malloc'ed object in a
>> palloc'ed struct in pgsql, if the memorycontext where the struct
>> resides is cleaned up, you leak the GEOS object
>>
>> It's (2) which seems to require a callback and hooks to do memory work
>> inside the pgsql pools. BTW, the XML support in PgSQL also uses
>> callbacks to do the memory allocation inside the pgsql pools, I have
>> found. However, as a core module, they get to create their own memory
>> context and have a piece of code right in core that cleans up their
>> context at the end of a transaction block.
>>
>> If, alternately, the pgsql function manager provided a way to know
>> when fcinfo->flinfo->fn_mcxt was going to be freed, we could keep all
>> our GEOS objects in malloc'ed space and clean them up before the
>> context was freed.
>
> Ah but we do this in PostGIS already - this is exactly how I implemented
> caching for PROJ.4 objects :)
>
> The way it works is to attach our own set of methods to a new child
> memory context of the function context. Then when this is context is
> destroyed at the end of the query/abort, we can go through the list and
> free everything as required.
>
> Now the trick would be to do this hierarchically: say for example you
> have something like this in GEOS:
>
> Geometry
>   |
>  CoordinateSequence
>        |
>      Coordinate
>
> Thus each layer would store the list of malloc()d pointers for
> everything in the immediate layer below it. This would then mean that we
> would only need to track the topmost pointer within PostGIS since
> deletion of this object would automatically cause a cascade deletion of
> everything else.
>
>
> ATB,
>
> Mark.
>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>