[geos-devel] Unclear objects lifetime and ownership issues in Monotone Chain components

[Paul Ramsey]

Let's wait a couple days before declaring tighness one way or another,
as there are certainly gushing holes on the PostGIS side that I know
have enough info to go after.

P.

On Thu, Sep 25, 2008 at 5:23 PM, Martin Davis <mbdavis at refractions.net> wrote:
>
>
> Mark Cave-Ayland wrote:
>>
>> Martin, would there ever be a case where a hidden internal object could
>> be shared between multiple parent objects?
>>
>
> Um...  I'll say no, this is not a pattern which is intentionally used in JTS
> *at the level at which user functionality is concerned*.  Of course, in the
> internal graph structures there is lots of cross-pointing, but the lifetime
> of these structures is always well-defined.
> In general, if the goal is to expose the methods on Geometry which are used
> in PostGIS, then it should be possible to free all allocated memory when the
> method completes (apart from any returned geometry, of course).  The one new
> exception to this is the PreparedGeometry classes, which of course have to
> hold onto memory for their internal structures.  But their lifetime is
> well-defined as well.
>
> Hopefully that helps.  Is there a possibility of supplying a single pool to
> each new Geometry method, and freeing it at the end of the operation?
>  Although how would you allow returned Geometrys to be allocated outside of
> this pool...  But maybe that doesn't matter - you can just free the pool at
> the end of the PostGIS function.
> This seems like it might be building GEOS to be a bit too specific to its
> use in PostGIS, however.  I think there's lots of people who want to use it
> in other environments.
>
> Is GEOS really that far from being memory-tight?
>>
>> ATB,
>>
>> Mark.
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>