On Fri, Sep 21, 2007 at 02:11:43AM +0900, Chad Musick wrote: > > 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.
I'm wondering if there's a way to catch programmatic errors by a predictable exceptional condition rather then an unpredictable unlucky run of the collector... > > > 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. Yes we use many different kind of containers. And yes, it would be more complex to use a templated container class for this. I'm just trying to think of possible ways reduce chances of programmatic errors. --strk; _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
