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

[Martin Davis]

Would it be possible to use a hierarchical memory manager with GEOS?  
JTS algorithms tend to be fairly well-structured and hierarchical in 
their memory usage patterns.

It would take a bit of work to identify the patterns - but probably less 
work than understanding the algorithms enough to design a completely 
different codebase from the ground up.

Mark Cave-Ayland wrote:
> On Wed, 2008-09-24 at 22:50 +0200, Mateusz Loskot wrote:
>
>   
>> The only solution I can imagine is to take JTS algorithms, one by one,
>> re-analyse them and re-implement (sometimes re-design a little) having all
>> these issues in mind. So, final implementation fulfills requirements of
>> Martin's algorithms as well as fits well into conditions of C++.
>>
>> AFAIR, we've talked about these kind of problems in GEOS a few times
>> but no one is brave enough to apply discussed ideas to the code.
>> Everybody is able to imagine it would require a lot of work.
>>     
>
> I think long term that this will be the only sensible way to go. There
> are many different paradigms in programming which are incompatible with
> each other, and translating an algorithm direct from a GC environment to
> a non-GC environment is one of these IMHO.
>
> GEOS is a great proof-of-concept piece of code and we are all grateful
> to Sandro, Mateusz etc. for the work that they have put in. But the
> warning bells start to ring when even the people who work on the code
> are unable to understand or maintain it - a lot of the work in PostGIS
> SVN at the moment is related to tidying up code / adding debug support
> which is designed to simplify things for developers, and make us (me?)
> less likely to break things in the future when adding new features.
>
> If I had a choice then it would be to spend the time re-engineering
> Martin's JTS concepts/ideas into an algorithmic form which is friendly
> to the language it is being written in, rather than trying to hack in
> pointer reference counting. Work with the language, not against it. 
>
> Having GEOS shadow JTS would be great in a perfect world, but the
> reality is that the reduced cost in implementing new features comes at
> the massive increased price of ongoing maintenance. While we are there,
> let's chuck in a hierarchical memory manager (like PostgreSQL's palloc()
> - maybe Samba's talloc() ?) so we can reclaim memory on a per-context
> basis and eliminate memory leaks at the same time.
>
>
> 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