[Gdal-dev] Re: DeleteLayer problems

[Kevin Ruland]

Frank,

Right now, in the current ng bindings, when a Band (script) object goes
out of scope, and calls it's script destructor, it does not in turn call
any GDAL C library methods to free resources.

You can of course still get in trouble by referring to Band objects
after the Dataset has been deleted, ie,

ds = gdal.Open("cint16.tif")
band = ds.GetRasterBand(1)
ds = None
print band.DataType

This code snippet didn't segfault/core on my system but it did print
complete trash.

Kevin

Frank Warmerdam wrote:

>On 8/19/05, Kevin Ruland <kruland at ku.edu> wrote:
>  
>
>>Charlie,
>>
>>Yes, that is a problem and is very similar to the GDAL problem of
>>deleting a Dataset when you still have a reference to a Band it
>>contains.  Unfortunately this problem is in the underlying C++ code and
>>I don't think there is a whole lot we can do about it in the wrapper layer.
>>    
>>
>
>Kevin / Charles, 
>
>I think part of our problem with layers, and bands is that they aren't
>owned by the script variables that reference them.  They are owned
>by the OGRDataSource and GDALDataset objects.  
>
>My feeling is that the ogr.Layer and gdal.Band script objects should
>*not* be taking and dropping references to the layer and band.  That
>should mean that it doesn't matter if an ogr.Layer is released after
>the corresponding ogr.DataSource since the ogr.Layer cleanup code
>does not actually invoke any code on the layer. 
>
>Note that the above situation is different than the issue with featuredefns.
>There, as I mentioned in the other email, I believe the solution is to properly
>manage the reference counts.   The OGRFeatureDefn class is distinct
>from the OGRLayer itself, in part, so that OGRFeature's can exist without
>a corresponding OGRLayer object. 
>
>Hopefully, as long as we arrange the script bindings to honour the
>underlying GDAL/OGR ownership/reference counting conentions
>*and* fix OGR to do it's reference counting properly, we will be in the 
>clear. 
>
>I must admit that non-deterministically garbage collected languages
>do bring out these issues. 
>
>PS. I do think these conversions would be best held on gdal-dev.  
>It would help make others aware of some of the issues, and directions
>of development.
>
>  
>