[postgis-devel] lwgeom_free()

[Paul Ramsey]

Wiki page updated, now with pretty pictures.

P.

On 2010-12-11, at 2:18 AM, Nicklas Avén <nicklas.aven at jordogskog.no> wrote:

> 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
>> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel