[postgis-devel] lwgeom_free()

Paul Ramsey pramsey at opengeo.org
Fri Dec 10 16:37:21 PST 2010


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



More information about the postgis-devel mailing list