Re: [Openev-discuss] Gtk Signals and destroying a layer from the viewer

[Diana Esch-M. <des...@la...>]

Gillian,

I had the same thought about the interplay of the python garbage
collection and the gtk process.Indeed the reference count was 2 at the
unref in gvviewarea_remove_layer() because the python code
 image=self.viewarea.get_named_layer(self.image_name) causes it to be
incremented one and it doesn't get decremented until the routine exits,
thus setting off the destroy process! Restructuring the code to:
            
self.viewarea.remove_layer(self.viewarea.get_named_layer(self.image_name))

without the interim variable makes it occur instantly! Uggh! I may just
take the time to write up some notes so that others may not have to be
so diligent (aka frustrated) in figuring out how all the
destroy/finalize stuff works with RasterLayers, Rasters, etc. I also had
to understand the gdal.Open and gdal.Dataset (__del__) vs GDALOpen() and
GDALCLose() to figure out the interplay between OpenEv and gdal and
dataset ref counting. So do you agree that the GDALCLose() is
incorrectly coded for not checking the shared flag? I say it should be:
/* --------------------------------------------------------------------
*/
/*      If this file is in the shared dataset list then dereference    
*/
/*      it, and only delete/remote it if the reference count has       
*/
/*      dropped to zero.                                               
*/
/* --------------------------------------------------------------------
*/
    for( i = 0; i < nSharedDatasetCount; i++ )
    {
    papoSharedDatasets[i]);
        if( papoSharedDatasets[i] == poDS && poDS->GetShared() == TRUE)
        {
            if( poDS->Dereference() > 0 )
                return;

            delete poDS;
            return;
        }
    }





On Fri, 2003-08-01 at 07:46, Gillian Walter wrote:
> Hi,
> 
> I've never looked at the gtk destroy stuff in much detail, but the only 
> things that I could think of offhand were:
> 
> a) If the destroy stuff was being done in an idle handler, things might 
> be delayed (I had a quick look, I don't think that's the case),
> 
> or
> 
> b) The reference hasn't actually gone to zero yet (maybe something is 
> being retained because of the python bindings or gv_manager- does using 
> get_named_layer up the reference count on the layer or raster until 
> image disappears from scope?  Can you check the object's reference count 
> before it gets unref'd at the point where it looks like it should go 
> into the destroy from the code?  How are you tracing the signal?  Are 
> you using print's?)
> 
> These are just speculation though.  Let me know when you figure it out- 
> I've had difficulty trying to follow gtk/python garbage 
> collection/destroy related code.
> 
> Gillian
> 
> Diana Esch-Mosher wrote:
> 
> >Oh, the gore of the gtk object system!!!
> >
> >So I'm trying to understand the "destroy" process and signal timing. In
> >my app I remove a layer: 
> >            self.viewarea.get_named_layer(self.image_name)
> >            self.viewarea.remove_layer(image)
> >shortly following in the code I have:
> >            self.file_open_by_name(filename)
> >            self.image_name=filename
> >
> >But tracing what happens (and more importantly when) I see that the
> >file_open_by_name operation occurs before the remove_layer has gone
> >through the whole destroy and finalize process. 
> >
> >Now let me see if I understand. In gv_viewarea_remove layer() the
> >teardown is generated and I see this signal is processed immediately,
> >the gtk_object_unref should then start the whole destroy process -
> >right? But I see the processing for the new file I'm adding to the view
> >coming next. Next, I see each destroy for each band with the
> >accompanying catches of the destroy signal to the
> >gv_manager_rester_destroy_cb(). Finally ending in the
> >gv_raster_finalize() with a ref count of 0 that GDALClose() the file.
> >Whew!
> >
> >So, two questions. Why is the destroy process not occurring first. Or,
> >in other words, is there some signal timing I don't quite understand.
> >When a signal is generated is it not processed immediately? Secondly,
> >the code in gv_manager_raster_destroy_cb:  
> >
> >if( GDALDereferenceDataset( ds->dataset ) < 1 )  GDALClose( ds->dataset
> >);
> >
> >seems a bit odd. I understand that you need to deref the counter because
> >you have 1 for the dataset in general and one for each of the bands.
> >Here is where you are deleting the general one But, the raster destroy
> >process seems to be such that the manager_cb is processed first and thus
> >will never be dereferencing to the point to be able to close! Or, put
> >another way, raster_finalize always does the close! By what path would
> >the close ever be invoked here ... or is it just a precautionary code
> >with possibly odd signal timing/handling? 
> >
> >Inquiring minds want to know ..............
> >
> >
> >Thanks,
> >	    
> >  
> >
-- 
Diana Esch-Mosher <des...@la...>
Los Alamos National Laboratory