[geos-devel] An Immodest Proposal

[Greg Troxel]

  We have recently found one such problem pattern. When using
  preparedgeometry in postgis, we create a GEOS geometry and associated
  prepared geometry, these are duly malloc'ed, but we store references
  to them in a palloc'ed struct in a memory pool which lasts for the
  life of a postgres query.  All is good (well, there are memory leaks
  in the prepared stuff still, but those are theoretically fixable)
  until the end of the query, when postgres cleans up the query memory
  pool. All of a sudden the struct with the references to the geometry
  and prepared geometry are gone -- but the objects have not been freed.

Your proposal sounds sensible to me.  An alternative, much less
palatable, is to head down the path that guile takes with SMOBS, where
each object has a free routine, and to have the cleanup function for the
pool deallocate external pointers.  This assumes the pool is cleaned
instead of just being freed en masse like an exiting process, and even
if it worked it seems more complex and harder.

One concern would be if geos objects created in this way end up shared
in multiple pools, or are ever referred to by anything outside of such a
pool.  I can certainly believe that the usage patterns in postgis mean
that my concern is at the moment unfounded, but the palloc strategy
forces an invariant onto postgis that should be clearly documented lest
someone later not understand the implications.

I am woefully unclear on threading and geos.  Probably the rule for the
init function is that one has to call it before doing any other
operation (to avoid alloc-native/free-palloc), and then one may not
change the function again, at least not while any objects are allocated.

What happens when the two 'std alloc!' allocations get freed with the
new free function at process exit?  (Or if they don't now, when the bug
that leaks them is fixed?)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/geos-devel/attachments/20080930/f0ba2736/attachment.bin