RFC-24 Mapscript memory management: call for comments

[Tamas Szekeres]

2007/1/13, Frank Warmerdam <warmerdam at pobox.com>:

> My opinion is different.  The map is the main object, and I think it
> is up to applications to keep a handle to the map as long as they want
> to do stuff, and once the map is released (dereferenced) the
> application  should not use any part of the map.

That's not so easy to realize. The scope of the object references with
some languages might be somewhat different as we would expect compared
to the common C/C++ rules.
I can flash this issue out according to the C#/.NET implementation but
I have not too much information about the other bindings.
Consider the following example:

<CODE>
parentObj parent = new parentObj();
childObj child = parent.getChildObj();

// at this point there's no more references to 'parent' so it might be
garbage collected

child.OperateOnChild();  // will cause access violation
</CODE>

There are some built-in mechanisms how the user can guard against this problem.
The most trivial option was to use the GC.KeepAlive function as:

<CODE>
parentObj parent = new parentObj();
childObj child = parent.getChildObj();
child.OperateOnChild();
GC.KeepAlive(parent);
</CODE>

GC.KeepAlive will keep the reference alive until the location of this
(KeepAlive) function.
Alternatively the user could use HandleRef-s or SafeHandle-s along
with the 'parent' to achieve similar results.
Obviously, it's very difficult to take care of all the compicated
situations that might arise, so
it would be unwise to leave this issue up to the woeful interface user.


2007/1/13, Howard Butler <hobu at iastate.edu>:

> If we've given MapServer enough information to know about its
> objects, MapServer should take care of doing the right thing with
> them.  Another strike against implementing it where RFC 24 currently
> proposes is that it does nothing for PHP/MapScript or MapServer CGI

That sounds compelling, but I cannot really imagine how to realize it
without altering the various SWIG bindings.
For example if we would want to implement a kind of reference counting
on the mapserver structures, we could always increment the refcount of
the mapObj when returning references to the contained layerObj-s.
mapObj should only be deleted, when it's reference count reaches zero.
But it implies that the SWIG should always consider true ownership on
all objects and call the corresponding Release or Delete method at the
finalizer of the wrapper object. That is currently not the case.
But, let's talk about such an implementation in more detail!

So again, at this point I would suggest to focus on the problem 2.2
and 2.3 respectively.


Best Regards,