References and scripting language bindings

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

References and scripting language bindings

Ari Jolma
Hi, this problem was discussed on IRC yesterday but I'm slow to
understand, so I try to describe the problem again and think about a
solution.

The problem is that if you do something like

layer = datasource.Open('data').GetLayerByIndex(0)
print layer.Name

this will cause a problem if the scripting language has deleted the
datasource (and the layer with it). This is  because it was just a
temporary variable. I first thought that layer should be undefined on
the 2nd line. But this is analogous to the case if you create a
reference to a variable and there scripting languages typically do not
delete the variable until the referencing variable is not used anymore
(it goes out of scope for example).

The datasource class (and many other classes) in OGR has similar
reference count system. Thus I think we should use them in the scripting
language bindings. I.e. do not destroy a datasource object if it has
references to it. In GetLayerByIndex increment the reference count. In a
layer object make a note which datasource object it needs and decrement
the count of that when the layer object it destroyed.

Is this difficult to implement in swig? The problem seems to be where to
put the link to the parent (e.g. the datasource handle for the layer
object)? It has to be done while still in the C wrapper.

I don't know how all this works in Java which has a different kind of
garbage collection system.

Ari

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: References and scripting language bindings

Kevin Ruland
Ari,

You understand perfectly.

The solution you propose is also correct.  But it needs to be done "all
the way down" to support longer chains of calls:

f = ogr.Open('data').GetLayerByIndex(0).GetFeature(0)

It seems that everybody down the stack will need to know the root
datasource.

This does pose some interesting problems though, right now,
GetLayerByIndex() does not return an object owned by the script (ie, not
a %newobject).  It will need to return a new object which has some
control over a dataset pointer.  etc.

It will be a little piece of work.

Also, I'm hearing there is a similar situation in the FeatureDefn &
FieldDefn objects.

Kevin

Ari Jolma wrote:

> Hi, this problem was discussed on IRC yesterday but I'm slow to
> understand, so I try to describe the problem again and think about a
> solution.
>
> The problem is that if you do something like
>
> layer = datasource.Open('data').GetLayerByIndex(0)
> print layer.Name
>
> this will cause a problem if the scripting language has deleted the
> datasource (and the layer with it). This is  because it was just a
> temporary variable. I first thought that layer should be undefined on
> the 2nd line. But this is analogous to the case if you create a
> reference to a variable and there scripting languages typically do not
> delete the variable until the referencing variable is not used anymore
> (it goes out of scope for example).
>
> The datasource class (and many other classes) in OGR has similar
> reference count system. Thus I think we should use them in the
> scripting language bindings. I.e. do not destroy a datasource object
> if it has references to it. In GetLayerByIndex increment the reference
> count. In a layer object make a note which datasource object it needs
> and decrement the count of that when the layer object it destroyed.
>
> Is this difficult to implement in swig? The problem seems to be where
> to put the link to the parent (e.g. the datasource handle for the
> layer object)? It has to be done while still in the C wrapper.
>
> I don't know how all this works in Java which has a different kind of
> garbage collection system.
>
> Ari
>
> _______________________________________________
> Gdal-dev mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/gdal-dev


_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: References and scripting language bindings

Frank Warmerdam
In reply to this post by Ari Jolma
On 9/15/05, Ari Jolma <[hidden email]> wrote:
> Hi, this problem was discussed on IRC yesterday but I'm slow to
> understand, so I try to describe the problem again and think about a
> solution.
>
> The problem is that if you do something like
>
> layer = datasource.Open('data').GetLayerByIndex(0)
> print layer.Name

Ari,

To clarify for the list the problem you point out has
existed in the Python OGR bindings (and for that matter
in the GDAL bindings) as long as they have existed.  The
requirement so far has been for the script writer to keep
a reference to the datasource until they are done using
objects owned by the datasource such as layers (or bands
in GDAL's case).

While this is not a terrible onerous requirement, it does violate
the reasonable expectation of the scripter, and introduces an
easy way to cause unexpected crashes which is undesirable.

So, the "safe" version of your code would be:

ds = ogr.Open("data")
layer = layer.GetLayerByIndex(0)
... do stuff with layer

ds = None  
l
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Gdal-dev mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/gdal-dev