Re: [Gnash-dev] GC: texture_glyph and private dtor/copy

[strk]

On Sat, Jun 16, 2007 at 02:54:17AM +0200, strk wrote:
> On Fri, Jun 15, 2007 at 06:25:14PM -0600, Eric Hughes wrote:
> > At 05:50 PM 6/15/2007, strk wrote:
> > >Both GC and RC ? Do you really want to go there ?
> > 
> > Well, I've always seen RC as special case of GC, one that's not reliable in 
> > general.  A reference count can be seen as a memo of the number of incoming 
> > edges.  It would seem that there may be some benefit to combining the 
> > mechanisms.  But like I said before, my desiderata was simplicity of 
> > interface--nothing else.
> 
> The benefit would be that known-to-be-unreachable would be released
> and removed from the GC list of maintained pointers earlier.
> Would take an interator into the GC list (most likely a pointer
> to a node of a doubly linked list) for each "managed" object
> and wouldn't remove the cost of ref counting (shouldn't be too high).

I think embedding this iterator thing in GcResource would actually
help us in the short term, as I'm getting bugs due to non-GC controlled
deletions releasing GC-managed pointers.
These kind of errors are NOT easy to debug with my valgrind strategy..

Quickly 'grepping' for delete does show more then I'd like to see,
so it would be nice to decide wheter we want to remove them
or not (assuming a closer look reveals they are safe [ie: it is ensured no
other references to those objects exist]). 

I'll take a closer look, but I'm more inclined to remove them then to 
support them.

--strk;