Re: [Gnash-dev] Re: Garbage Collection

[Chad Musick]

> > (This example made me change the 'manage' function in the GC to use
> > GcInvoke, since I realized that the problems of doSomething1()
> > doSomething2() make it unsafe for 'manage' to immediately cause
> > management -- I was properly handling 2), but not 1))
> 
> Would a GC::manage() call outside of GcInvoke presence cause an assertion 
> failure 
> or equivalent exception ?
> 
No, but it might cause temporarily unreachable objects to be deleted.

> > Example:
> > class func_obj { public: operator() { member = new GcObject; } .... };
> > Assuming that func_obj properly marks all of its members and such, this
> > is still not safe, because the allocation of member is not done within a
> > GcInvoke scope.  Doing this:
> > someFunction1() { GcInvoke myInvoke; boost::thread T(func_obj()); }
> > does not make it safe -- the func_obj cannot benefit from the GcInvoke.
> > This is bad practice anyway.
> 
> Alright, the example above is bad becuase operator() is allocating w/out 
> stack-allocating
> a GcInvoke, right ? Would a GcInvoke in operator() make the latter safe ?
> 
>  class func_obj { public: operator() { GcInvoke myInvoke; member = new 
> GcObject; } .... };
>  someFunction1() { GcInvoke myInvoke; boost::thread T(func_obj()); }
> 
Yes, that would fix it.

> > The reason is that the GC uses the iterators to mark containers and
> > invalidating the iterators may make the Gc de-reference or increment an
> > invalid iterator.
> 
> This makes me think a GcManagedContainer class would be appropriate here,
> to be used whenever the container contains GC-managed objects.
> The class could take care of proper locking, what do you think ?
I think this is unneeded complexity -- external locking allows the
marking of any container which can use iterators.  Currently, we use:
std::map, std::vector, std::list that I know of.  Possibly std::set as
well, I haven't checked.

Chad