|
Hi Robert and Jose,
osgIntrospection does not add or remove any memory
management mechanisms, so the problems of integrating two languages through
osgIntrospection are the same as if you do that without using osgIntrospection.
The fact that storing a raw pointer in a Value might leak memory is not related
to how osgIntrospection works, it is the correct behaviour if you think of Value
as a container for C++ objects (where "object" here has the meaning
defined in the C++ Standard document). Even if you don't use any
introspection layer, creating an instance of some type with operator new and
then letting the pointer variable go out of scope will leak memory.
The problem here is about integrating two memory
management mechanisms, and the solution is: don't integrate them.
osgIntrospection should be able to reflect ref_ptr'd types just fine, so
you can use reflected ref_ptr's in Lua through osgIntrospection itself,
which lets you continue to use the OSG memory management system for
OSG types. You should do some experiments on that though, because I'm a bit
rusty on osgIntrospection even though I wrote it... :-)
The only limitation, besides the added syntax
complexity, is that class templates cannot be reflected directly as they are not
C++ types (they are just *templates*). So you can't reflect osg::ref_ptr, but
you can reflect osg::ref_ptr<int>, osg::ref_pt<osg::Object> and so
forth. This implies that for any type T genwrapper must encounter
ref_ptr<T> in source code at least once in order to reflect it and make it
available to osgIntrospection users. If you need a reflector for
ref_ptr<T> but it is not provided by default OSG wrappers (because T is
never used through ref_ptr<> in the public interface of any OSG class),
then you can add it by yourself, even in a separate shared library.
Cheers,
Marco
----- Original Message -----
Sent: Friday, September 08, 2006 1:13
PM
Subject: Re: [osg-users]
osgIntrospection: how to handle pointers, references,...
Hi Jose,
I'm hoping that Marco Jez will step in a
discuss some of osgIntrospection issues as he's the author of it, and as yet I
haven't got to grip with all its design and working. There are some
known memory leaks in osgIntrospection that need to be fixed, but I'll need to
get closer to the code than I am now to track them down and provide a robust
fix. There should be some disucssion in the archives on the this topic
form when osgIntrospection was first introduced.
On the Lua side I
have integrated the OSG with Lua using swig (I have been planning lua
integration via osgIntrospection but wished first to learn more about Lua
first). Garbabe collection is something that I had to be addressed,
since both the OSG and Lua have their own memory management - the OSG via
osg::ref_ptr<> and osg::Refernced, and Lua via garbage collection.
Now ref_ptr<> are perfectly safe to garbage collect so if when
you create an OSG object (one subclassed from osg::Referened) you handle this
on the Lua side as a ref_ptr<> rather than as a C pointer then.
Not all OSG objects are subclassed from osg::Referenced though, things like
Vec3 and built in types etc, this are safe to create and delete on the stack
or heap, so as long Lua does the garbage collection on them then everything
should be fine.
Going via osgIntrospection does add an extra
complication, that I'll leave to others with a more intimate understanding of
osgIntrospeciton to shed light on. I do plan to get a better
understanding of osgIntrospection, but that is not time the 1.2 release time
frame ;-)
Robert.
On 9/8/06, Jose Luis
Hidalgo <[EMAIL PROTECTED]>
wrote:
Hi
all,
Let's imagine I'm trying to use osgIntrospection to
make a
scripting language (hmmm LUA for example) be able to access
everything
that is been reflected in osg. That's fine, it's quite easy
to use
lua's beautifull mechanisms to know what the user is trying
to
instance or what method is trying to invoke. Everything
dynamic,
generic, and whatever class of osg is accessible with no cost.
(Ok, up
to here is osgLua and works pretty
well)
But... Lua is a garbage-collector based
scripting, if someone
instances something the user expects that the GC
take care of the
data. That's true, actually osgLua takes the
osgIntrospection::Value
and destroys it... but, Value will not destroy
the data:
///
Destructor. Frees internal resources but it does NOT
delete
/// the value
held. For example, this function will produce
a
/// memory
leak: void f() { Value v(new int); }
inline
~Value();
This can cause memory leaks if the user doesn' t take care
of it...
(and I'm trying to avoid that) but moreover, for example, if the
user
gets from the current scene a node, since osgLua do not increment
its
reference, the node can be freed and the script still have a
reference
that could be null...
I'm wondering possible solutions
to that problem, I came with one that
is quite easy but I want to discuss
it:
Make lua to act as a very big ref_ptr handler, if the object
inherits
from Referenced then lua uses ref, unref mechanism to handle it.
But,
what will happen to those objects that are not referenced? do
they
exist in osg? (I'm not sure) How to handle them? Should I make lua
only instances referenced
objects?
Cheers,
Jose
L.
--
Jose L. Hidalgo Valiño
(PpluX)
---- http://www.pplux.com
----
_______________________________________________
osg-users
mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing
list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
|
