[Gdal-dev] Re: GetGeometryRef in scripts

[Charlie Savage]

> An object must know about its' container, so that when the object is 
> really destroyed, the destructor needs to check the container, and 
> destroy also it, if it isn't referenced by anybody else.

In OGR an object does not know its container.

> When a container is really destroyed, all the objects that it contains, 
> are also destroyed. If an object, which is thus being destroyed, is 
> referenced by somebody, then it must clone itself and continue living.

The other way to look at this, and I think a simpler way, is that you 
must not use an object once it has been destroyed by its container 
(because the container was destroyed).  Thus the discussion centers 
around how you keep the container alive.  Is it up to the script writer 
(by holding references)?  Or is there something that we can do in the 
SWIG interface to help out?   The two possibilities that have been 
discussed are reference counting (complex) and having the child 
scripting object have a reference to its parent (simple, leverages the 
languages garbage collector, but does not work for all languages).

> I don't see it impossible to implement this in the thin C/C++ layer 
> between scripts and GDAL. As far as I understand the only important 
> missing piece is the link from an object to its container. 

There is no such link and thus this would require either an extensive 
rewrite of OGR or a whole lot of complicated code in the SWIG binding. 
And in the end, I don't see what you gain from it but slower code 
because I think there will be edge cases where you can subvert this 
layer and get in trouble.  Better to keep things simpler.

 > That's also a rule: an object can be (owned) in only one container.

Already true.

> The variables in the script are always just references to the actual 
> objects under the hood. The engine below must take care that the correct 
> objects exist. It is difficult because we're just responding to messages 
> (like in GUI programming) and do not have complete control.

I actually think the better approach is use the garbage collector of the 
scripting language (i.e., how to keep the container alive as discussed 
above).  Otherwise we end up with memory managed in 3 places - the 
scripting language, the wrapper code, and GDAL/OGR.  Its already hard 
enough in 2 places!

Charlie


> Kevin Ruland kirjoitti:
> 
>>
>>> Perhaps you could clarify where we have problems with gc languages.  
>>> I *feel* this isn't a problem, because language
>>> variables that reference objects should not need to do anything
>>> at all for objects they don't own.  So, for instance, a reference
>>> to a geometry that is owned by some other object does not need
>>> to do any work at all in it's destructor other than check it's
>>> "owned" flag.  
>>>
>>
>> Frank,
>>
>>
>> I had had this nice beautiful description of the nasties complete with 
>> alusions to the dispicable state of US politics, but after reading 
>> through the ogr.i code, I wonder if the original source of the problem 
>> is really my bug in the ogr.i interface description
>>
>> I see that r1.35 of ogr.i on 8/22 I checked in a change which added 
>> %newobject to both Layer.GetFeature and Layer.GetNextFeature.  Recall 
>> that %newobject tells the script that it owns the returned pointer and 
>> will call the destructor (which is OGR_F_Destroy()).
>>
>> Could this be the source of the original angst?  It probably isn't 
>> because chained calls still wont work because you'll end up with a 
>> dangling reference.  However, it probably does fix my percieved gc 
>> problem between layer and feature.
>>
>> Unless Charlie can tell me otherwise, I don't think there is a 
>> potential gc problem between Datasource and Layer anymore.  The 
>> destructors for layer are noops so they should be able to succeed 
>> after calling the datasource destructor.  This is of course dependent 
>> on the assumption that the datasource reference is maintained during 
>> the lifetime of the layer.  Charlie has pointed to problems between 
>> FeatureDefn and FieldDefn, but you have already assumed ownership of 
>> this.
>>
>> I think it would be useful for my sanity if you could walk through 
>> ogr.i and look at the various methods which create or consume 
>> pointers.  Any function which returns a pointer owned by the script 
>> needs to have %newobject.  Any function which assumes ownership of a 
>> pointer needs to have a DISOWN typemap.  I see that Layer has things 
>> like SetFeature and CreateFeature, I suspect they should be using 
>> DISOWN, but hey what do I know.
>>
>> Alas, I thought it was just last week when I apologized for blowing up 
>> a very similar issue over FieldDefn (cf. r1.41).
>>
>> Kevin
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
> 
> 
>