RFC-24: published implementation proposal on bugzilla

[Tamas Szekeres]

2007/3/16, Umberto Nicoletti <umberto.nicoletti at gmail.com>:

> >
> > 2. You've suggested to keep references to the parent objects at the
> > target language. How would you implement this?
>
> This is described in the rfc at 3.7 for Java and 3.8 for Perl, but as
> of now I am not sure if we really need it, that's why I have
> implemented the null parent check for the layer obj.
> We might choose to delay the application of this requirement to a second phase.
>

That would not be a good idea, since every parent-child relationship
suffers from the early GC issue. For example when the user retieves a
reference to the scalebarObj of the map object, mapObj may be
collected before using the properties of the scalebar.

> >
> > 3. How the original concept of the object ownership is altered by this
> > RFC. Who is responsible to create and finally remove a particular
> > object? The C refcount implementation impresses that those objects are
> > self owned (controlled by the refcounts), but the comments at 3.2
> > shows that the original concept should be retained (So that finally
> > the child should be controlled by the parent).
>
> I think that the best and maybe only way for me to explain was to
> actually write the code. Please have a look at the freeLayer, freeMap
> and the unit tests and come back to me if you have further issues to
> discuss.
>

Hmmm.... It appears that the layerObj-s and classObj-s are considered
as self-owned objects and the target language should always call the
destructor on these objects. However there are some other code
fragments that deny this statement as the cleanup code at mapraster.c
(1689) for example.
BTW is the parent pointer check at 1415 correct (it does not call the
cleanup code)

> >
> > 4. I consider the decrementation of the refcount cannot be used solely
> > without controlling the destruction of that item like in layerObj
> > *msRemoveLayer(mapObj *map, int nIndex). What to do if the refcount
> > reaches zero in this case?
>
> msRemoveLayer will never decrement the refcount to zero but will leave
> it always to at least one (depending if the layer was dinamically
> added to the map).
> Example:
>
> I remove the first layer from the tests/test.map in mapserver distribution:
> initially the refcount of the layer is 1 because the map has one
> reference. After removal a new layerObj is created in mapscript so the
> refcount is still one. If the layer is added to another map the
> refcount of course increases, else if the layerObj goes out of scope
> and is gc'ed the memory will be freed because the refcount drops to
> zero.

msRemoveLayer should do it's own work without making assumptions how
the layer is used externally. Therefore if the refcount reaches zero
it *should* release the underlying memory. If msRemoveLayer is
expected to increment the refcount of the returned layer it should not
call MS_REFCNT_DECR at all. Otherwise the caller should call
MS_REFCNT_INCR before calling msRemoveLayer.
Recall, that the C# garbage collector is fairly agnostic and has the
face to GC mapObj during the pending removeLayer call if there's no
more references to mapObj at the subsequent code. (the object may go
out of scope before reaching the end of the function or the closing
brace).


I think it would be the right time to consider how the interface
should be rationalized, which objects are considered as root objects
and should be externally creatable. Does it make sense to allow
creating free-standing layers and later adding them to maps, or allow
taking a layer form one map and passing it to another? I guess in the
latter case not all of the potential problems are taken into account,
and we might get many of the MS_PARENTERR errors afterwards.


Best regards,

Tamas