[postgis-devel] lwgeom_free()

[Nicklas Avén]

wow, now the pieces are falling in place and I think I understand :-)

The wiki-page is great too. Will you add a note in the wiki about the
read-only flag for the point-arrays in deserialized geometries too? 

That part gave me a great part of understanding for how things are put
together. 

I think we should arrange a part of the wiki only for this type of
documents. Now it is disappearing a little behind things like my
description of distance calculations and so on and hopefully it will be
a bunch of documents over time describing the API.

It would also be nice to put links in the text to functions in DOxygen.
I can try to do that. I would like to link to both postgis doxygen and
postgresql doxygen.


Thanks


Nicklas




On Fri, 2010-12-10 at 16:37 -0800, Paul Ramsey wrote:
> Important development note:
> 
> As of <http://trac.osgeo.org/postgis/changeset/6340/> lwgeom_free()
> will now free *everything* underneath the lwgeom argument. The only
> exception is for POINTARRAYS that have been constructed with
> ptarray_construct_reference_data(), which will have had their
> FLAGS_READONLY bit set.
> 
> The idea is that the deserialize functions now construct READONLY
> POINTARRAYs on top of the database serialization (as before, actually)
> while the WKT and WKB constructors allocate fresh memory that is owned
> by the POINTARRAYs.
> 
> If you have code which is freeing the POINTARRAYs directly, or mucking
> with the serialized_pointlists (you shouldn't, I've attempted to clean
> it all out before doing this) please go through it.
> 
> Mark, I refitted the shp2pgsql-core.c to use lwgeom_free and the
> LWGEOM API more directly. It should still be clean, memory-wise, but
> if you have some tests handy to confirm that, please run them. It was
> the one really obvious case where serious by-hand memory management
> was going on.
> 
> Nik, I added the lwfree to the lwpoint->bbox you mentioned before, I
> think. You should find that you can now lwgeom_free your constructed
> objects and have things clean up perfectly underneath you.
> 
> Side note, this was all impossible until recently because the WKT
> parser built a serialized_lwgeom in a memory segment, then built the
> LWGEOM on top of that, so if you hand-built an LWGEOM there was a good
> chance it didn't own its own memory, so it always had to be cleaned up
> by hand. Now that the WKT/WKB parsers generate LWGEOMs that do own
> their memory, it's possible for them to clean up after themselves.
> 
> The tickets for addpoint and removepoint are probably next up, as well
> as a quick review of functions that might try and alter geometries
> in-place, to make sure the API is clear on what is going to happen to
> them.
> 
> Yours,
> 
> Paul
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>