[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] GC: texture_glyph and private dtor/copy
From: |
strk |
Subject: |
Re: [Gnash-dev] GC: texture_glyph and private dtor/copy |
Date: |
Sat, 16 Jun 2007 02:54:17 +0200 |
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;