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

[strk]

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).

The downside is that the current *intrusive* way of doing ref-counting
can't work, as it relies on the pointed-to object to be alive for
the whole lifetime of the containing smart pointer. Anyway we may want
to add a different implementation once the abstraction / interface
is stable.

> >Can't we just rely on the programmer to know what
> >he's doing and NOT registering the instance with the GC ?
> 
> Things change.  An original coder probably knows better.  One making an 
> incremental modification may not.  The most obvious error would be adding a 
> reference to an existing non-GC object from a new GC object as an 
> incremental addition and not realizing there's a need to add gc_ptr<> to 
> the old declaration.

I'm not sure I'm understanding this case.
The current GC doesn't rely on transparent referencing for the mark scan.
Failing to register a resource with the GC would result in leaks.
Failing to properly mark a registered and reachable resource would result in
memory faults.

> >Passing auto values around as pointers is a bug, I'd avoid complex solution
> >to make it safe.
> 
> Yes, passing pointers to auto values as such is unsafe.  Initializing a 
> managed object with one, however, need not be unsafe.  I have some ideas 
> about how to do this, if you're curious.

Sure, go ahead. 

> --------------------------------------------------------------
> 
> >Anyway suggestions for a better name are welcome.
> 
> How about "template< class T> managed_ptr ;"?

Good, will use that. Mind you will still just be a define for now ...

--strk;